2 P²I² Success Formula

Failure is often the first necessary step toward success. If we do not
take the risk of failing, we will not get the chance to
succeed. When we are trying, we are winning.

—Wynn Davis

What does it take to manage software risk? In 1992, I thought I knew the answer to that question. As the leader of a software risk management action team, my objectives, as stated in the process improvement plan, were clear: “Evaluate and enhance risk management practices from both a software and a programwide point of view, incorporate recommendations into command media, and develop training to comply with SEI CMM Level 3.” As a full-time member of the Software Engineering Process Group (SEPG), I was charged with improving the software process for the Information Systems Division at Harris Corporation. It would be a challenge to assemble a cross-functional team of division practitioners to agree on risk management practices. That was just the beginning of my role in the software community as a risk management champion.

A champion is a change agent: someone who maintains focus on the goal, strives to overcome obstacles, and refuses to give up when the going gets rough [Humphrey89]. As a risk management champion, I have refined risk management practices using my experience in applying an ivory tower–conceived process to software projects within industry and government [Hall95]. The key to sharing lessons learned from this experience is the feedback I have received from people who participated in learning and trying the new methods. From my perspective, both the success and the failure of the methods were significant in providing insight into the success formula for managing software risk that I present in this chapter.

In this chapter, I describe the major factors that affect risk management capability, which is the range of expected results that can be achieved by implementing a risk management process within an organization. I provide insights and lessons learned the hard way to help you avoid the pitfalls of adopting risk management.

This chapter answers the following questions:

What are the four major factors in risk management capability?

How can you overcome the barriers to adoption of risk management?

Why is the risk management process necessary but not sufficient?

2.1 Major Factors in Risk Management Capability

Successful project managers maintain a focus on their project’s critical success factors [Boehm91]. Similarly, to manage risk successfully, we should maintain focus on the four critical success factors of risk management—people, process, infrastructure, and implementation—denoted by the P²I² Success Formula (see Figure 2.1).

People participate in managing risk by implementing the risk management process according to the risk management plan. As long as people engineer software systems, they will be a critical factor in communicating the issues, concerns, and uncertainties in their work that translate to risk. Section 2.2 describes key points of the human side of risk management. Part V of this book details case studies of how people work together to manage software risk.

Process transforms uncertainty (the input) into acceptable risk (the output) through risk management activities. Process is a major factor in risk management capability because it describes the steps to predictable risk management results. Section 2.3 describes key points of the process dimension of risk management. Part II of this book addresses the risk management process in detail.

Infrastructure specifies how the organization requires the use of risk management on projects by establishing policy and standards. Infrastructure is a major factor in risk management capability because it establishes the culture that supports use of risk management. Section 2.4 describes key points of the infrastructure dimension of risk management. Part III of this book addresses the risk management infrastructure in detail.

Implementation is the plan and methodology used to perform risk management on a specific project. Implementation is a major factor in risk management capability because it assigns to the project the responsibility and authority to execute the plan. Section 2.5 describes key points of the implementation dimension of risk management. Part IV of this book addresses the risk management implementation in detail.

2.2 People: The Human Element

The people factors of participation, ability, and motivation describe the human element in managing risk. Participation of management, customer, and technical team is a key factor to the success of communication regarding risk. The ability of individuals in managing risk will vary. Nevertheless, everyone must develop a minimum skill level in order to manage risk effectively. Motivation is the force that drives the continued use of risk management throughout the life of the project. The key points to remember regarding people and risk are the following:

Involve people at all levels in risk management activities.

Education, training, and experience contribute to people’s ability to manage risk.

People’s motivation for change must be sufficient to overcome the barriers to adopting something new.

Individuals have risk preferences that you can use to predict their behavior.

2.2.1 Involve People through Participation at All Levels

People drive the risk management process, infrastructure, and implementation and thus are the most critical factor in managing risk. People who contribute to quality circles, action teams, or engineering process groups may drive the risk management process definition. People in senior management drive the organizational infrastructure with respect to risk management policy. Those who work on projects drive the implementation of the risk management plan. Because different people are contributing, their actions need to be coordinated; often they are not. I have observed people implementing risk management with a flawed process and without adequate training. They may use a vague risk management policy without automated tools, then learn on the job as necessary. Through trial and error, they will figure out the process, infrastructure, and implementation. Unfortunately, most improvement programs for software organizations emphasize process or technology, not people. For a comprehensive guide to people management, I recommend reading Peopleware: Productive Projects and Teams[DeMarco87] and People Capability Maturity Model (P-CMM^SM), which provides a focus on developing an organization’s talent [Curtis95]. There is no substitute for people. Only people make decisions; without them risk management would not happen.

Figure 2.1 Success factors in risk management. This fishbone diagram illustrates the relationships among the factors that may influence an organization’s ability to manage risk. The success formula P2I2 denotes these four major factors: people, process, infrastructure, and implementation.

Assessments of a particular risk vary, depending on job category and level within the project hierarchy. Whereas management is focused on the project profit equation, the technical staff has primary responsibility for the software product. Each person has a specific task assignment, and the risks that concern an individual will be relative to his or her task success criteria. Customers, subcontractors, and end users have different perspectives that may contribute to a more complete picture of the software risk.

People at all levels can contribute to managing risk by identifying the uncertainty with respect to their assigned tasks. An example of communication of risk occurs in group discussions during risk assessments. When project managers are involved in a risk assessment, they usually identify risks in cost and schedule or their customer relations. In their words, aggressive schedules on fixed budgets and lack of customer involvement can be hazardous to the health of their project. Project team members identify technical risks, which are often the source of cost and schedule risks. If you ask the technical staff, they might say changing requirements is a risk. They have an increased awareness of deficiencies in the process, as is evident when they say their risk includes poorly conceived processes and lack of a development methodology.¹ Customers, when they are involved, typically identify risks in the management process, scarce resources, and anticipated requirements growth. Customers have said that the decision-making process is not rigorous and that proper attention is not given to obtaining an accurate estimation of the scope of the work. At lower levels in the project hierarchy, individuals have more detailed information that may not be visible from the top. Knowing the job category of the person to whom you are talking (e.g., quality assurance, configuration management) will give you a good indication of that person’s area of concern.

¹ Process risk has been consistently one of the top five risks identified during risk assessments in the 1990s, a change from the 1980s [Boehm89], when process was not in the top ten risk list. SEI can be credited with increasing the awareness of the importance of process in developing a quality software product.

It may be necessary to broaden your definition of team to include all people who have the ability to affect the project. Try communicating risk to this expanded set of team members, and note the short-term and long-term effects. Briefing the customer (also sponsors, investors, clients, or users) and upper management (also functional management, senior management, or board members) on risk assessment results may be a strategic move for project managers. Although there may be initial shock that “the project might not be as easy as we had hoped,” expanding the team to encompass customers and upper management will enable cooperative project management (project management is the management team responsible for the execution of the project) and allow you to manage risks outside the project locus of control. Including organizational management in the project team worked in the following case study of Project X.

At the Project X briefing on risk assessment results, the engineering director shook his head with a look of bewilderment on his face. He could not believe that his newest project had over 100 risk issues identified—and less than a month after the contract award. When the initial disappointment had worn off, this director worked closely with the project manager to support the project at the organizational level. One risk identified during the risk assessment was a concern that the team was not physically located together. With the support of the engineering director, the project team moved to a new location.

At project completion, the project manager gave a retrospective review of lessons learned. One was that colocation had worked well for relocated people. Those functions not colocated, product design and drafting, appeared less responsive to the needs of the team. In addition to reporting good project team cooperation and relationship, the project manager also mentioned positive customer attitude and working relationship.

In this case, participation by an extended project team in managing risks had included organizational management and the customer. Although we cannot attribute this project’s success to risk management exclusively, we can observe that communication of risk issues may be difficult at first, but may encourage success in the long run.

2.2.2 Develop the Ability to Manage Risk

Education, training, and experience contribute to a person’s ability to manage risk. Education begins with the awareness that risk is inherent in all large software systems—and the understanding that an increase in system complexity translates to an increase in risk. Consider the following conversation I had with Ned, a systems engineer and technical leader. After the proposal team assessed its top ten design risks, Ned said to me, “We need another number two risk. If we are SEI Level 3, then software development should not be the number two risk.” “Ned,” I said slowly, “the customer knows. They know that software development is a risk. That is why they require SEI Level 3 contractors. SEI Level 3 does not make risk go away. It just means that your organization is better prepared to handle the risk.”

When people know that risk is present, they can begin to search for it, discover it, and deal with it. Education is general knowledge about risk—including a history of why and how risk management has been applied to software systems. Education might include comparing the uses of risk management concepts in various industries, such as finance and insurance, with uses in the software community. It might also include studies of risks and risk strategies in various software application domains. When would anyone have a use for general knowledge about risk management? When managing risk without precedents. Imagine that you must reconcile a 30 percent probability of failing to meet a success criterion with a customer, who has your company’s 100 percent commitment to meet all contractual requirements. How will you justify 30 percent probability when you have no historical sample of similar events?² There are numerous perplexities of risk management that require applied intelligence. Education helps us to gain the basics that we need to reason about risks.

² Never attempt to justify a number that has no basis in reality. Discuss the issue by substituting words (e.g., unlikely, probably not, or little chance) for the numerical percentage that may not be accurate.

Training in basic risk concepts provides a vocabulary that the project team uses to communicate risk issues effectively and conveys specific knowledge about particular risks and known risk strategies. Training should encompass the methods of the risk management process and practice using those methods on current issues facing the project. Such practice doubles as an exercise in team building. In other words, risk management is a productive team-building activity. Advanced training—learning a risk analysis tool or learning how to conduct a risk assessment, for example—should be reserved for individuals performing these specific tasks.

Without proper preparation through education and training, you should not expect any new method to be accepted. Even with preparation, there is no substitute for experience, and experience often results in both success and failure. The key is to learn from your experience by asking three questions: “What worked?” “What did not work?” and “What can be improved?” Documenting the answers to these questions ensures that you will learn from your experience and will be able to share your knowledge to benefit other people.

2.2.3 Provide Motivation to Overcome the Barriers

Your organization’s motivation for change to the use of risk management must be sufficient to overcome the barriers to adoption. Even if an organization has many receptive people, change still takes time. Changes in skills or procedures may take only weeks, but changes in structure can take months, and changes in strategy and culture may take years. The longer it takes to change the organization, the harder it is to sustain the change. Compelling reasons that change is needed provide motivation for the use of risk management. Although there are many good reasons to manage risks, simply pushing the positive benefits for change can have the opposite effect. It is often more helpful to remove barriers.

Table 2.1 Force Field for Risk Management Adoption

Note: Driving forces provide the reasons for risk management adoption; restraining forces are the barriers to adoption.

Force field analysis is a technique to help people understand the positive and negative aspects of change. The force field analysis shown in Table 2.1 identifies the positives and negatives of adopting risk management. This technique helps people think about making the desired change a permanent one. It encourages them to identify internal and external forces that are drivers for the ideal situation [Brassard94]. In this case, the ideal situation is to manage risk routinely to achieve established goals. Teams should brainstorm their own list of forces to discover their reasons for adopting risk management and what work will be required to remove their barriers to adoption. The team should achieve consensus on the list of forces and their entries’ relative rankings. Then the members can work to reinforce the driving forces while eliminating the restraining forces. Driving forces should provide the motivation to overcome the restraining forces.

There are two sources of motivation: internal and external. When they are motivated internally, people behave according to what they perceive is important. When they are motivated externally, they have received support and encouragement from an outside source. People are motivated to different degrees through both internal and external sources. Only people who are appropriately motivated will continue to assess and control software risk. Progress in managing risk should be rewarded through periodic recognition, but the real reward comes from the opportunity to improve the work environment.

Figure 2.2 Decisions are made based on risk preference. This decision tree models one decision (the square) and one uncertain event (the circle). The decision to work as an employee for a guaranteed $25,000 or as a contractor for $40,000 depends on the probability (1-p) of winning a competitive bid. Given that the probability is unknown, you could predict what someone would decide if you knew their risk preference.

2.2.4 Use Risk Preference to Predict Behavior

Risk preference is an attitude toward risk that varies among people. Each person has a natural preference regarding risk that is based on his or her temperament. Genetics, experience, and body chemistry affect temperament. Temperament determines our behavior, because behavior is how we get what we want [Keirsey84]. Our own disposition is a basic drive that determines our actions, but these internal motivations are rooted in our subconscious desires. Basic temperament determines how an individual perceives risk. To create a risk-aware culture, we must understand and appreciate these differences among people. By knowing a person’s risk preference, we can anticipate what choices he or she will make.

An associate recently asked for my advice on whether to accept a three-month assignment as a part-time employee or to work as a contractor. The human resources manager had offered the employee position, but a competitive bid would determine whether he could perform the work as a contractor. Figure 2.2 shows the decision tree that models his decision, the chance event, and the possible outcomes. A decision tree is a tool to structure difficult decisions to understand the available options. The tree flows from left to right; the immediate decision is represented by the square at the left side. The branches emanating from the square correspond to the two choices available: work as an employee or bid the job as a contractor. Only one option may be selected. If my associate decides to bid the job as a contractor, the next issue is whether the bid is won or lost. The circle represents this chance event. The branches emanating from the circle represent the possible outcomes. The bid can be either won or lost, but not both, and no other possibilities exist. The values of these outcomes are specified at the ends of the branches. If the bid is accepted, my associate will earn 62.5 percent more for the same work. If the bid is not accepted, he will have to find other work. If he decides to work as an employee, he would earn a more typical salary with standard benefits. These outcomes are shown at the ends of the branches at the right. Which would you choose?

To learn how to recognize your own risk preference, review the decision tree model, select between the two alternatives, and then document the rationale you used to make your decision. Your attitude toward risk can be categorized as risk averse, risk seeking, or risk neutral.

You are risk averse if you have a conservative risk attitude with a preference for secure payoffs. People who are risk averse make good middle managers, administrators, and engineers. If you are risk averse, you are practical, accepting, and have common sense. You enjoy facts more than theories, and support established methods of working. Remembering, persevering, and building are activities at which you excel. You agree with the following statements:

I like being dependable, and I am usually punctual.

I am not likely to take chances.

I am responsible and prefer to work efficiently.

I am more service oriented than self oriented.

I value institutions and observe traditions.

If you are risk averse, your decision in the problem presented in Figure 2.2 will be sensible and realistic: to work as an employee. The unknown probability associated with the choice of working as a contractor would make that decision uncomfortable for you.

You are risk seeking if you have a liberal risk attitude with a preference for speculative payoffs. People who are risk seeking make good entrepreneurs and negotiators. If you are risk seeking, you are adaptable and resourceful. You enjoy life and are not afraid to take action. Performing, acting, and taking risks are activities at which you excel. You agree with the following statements:

I like action, and I act impulsively at times.

I seek excitement for the thrill of the experience.

I am resourceful and prefer not to plan or prepare.

I am more self oriented than service oriented.

I like to anticipate another person’s position.

If you are risk seeking, your decision in the problem presented in Figure 2.2 will be optimistic and fearless: to work as a contractor. You may not get the job, but if you do, the payoff will be worth it.

You are risk neutral if you have an impartial risk attitude with a preference for future payoffs. People who are risk neutral make good executives, system architects, and group leaders. Risk-neutral types are neither risk seeking nor risk averse, but rather seek strategies and tactics that have high future payoff. If you are risk neutral, you think abstractly and creatively and envision the possibilities. You enjoy ideas and are not afraid of change or the unknown. Learning, imagining, and inventing are activities at which you excel. You agree with the following statements:

I trust my intuition, and I am comfortable with the unknown.

I think about the future and have long-range objectives.

I am naturally curious and often ask, “Why?”

I enjoy generating new ideas.

I work best when I am inspired.

If you are risk neutral, your decision in the problem presented in Figure 2.2 will be based on what you believe will bring long-term benefits (e.g., career growth or an opportunity to travel). The monetary differential in the short term will not be the deciding factor.

2.3 Process: The Steps to Manage Risk

Process is a set of activities and mechanisms that people use to transform inputs to outputs. The process factors of definition and execution describe the standard steps to manage risk. The risk management process is a systematic and structured way to manage risks that includes the activities and mechanisms used to transform project knowledge into decision-making information. Activities describe the steps to transform uncertainty into acceptable risk. Mechanisms are the means that we use to accomplish each process activity. The key points to remember regarding the risk management process are the following:

There are five process elements in the risk management process.

The standard process is not one size fits all.

The defined process should be flexible.

The process execution must be cost-effective.

2.3.1 Learn the Five Process Elements

There are five essential elements of the risk management process:

1.Identify—identifying risk and sources of risk. When people have trouble discussing risk, we should ask them instead about their concerns, doubts, issues, and uncertainties. Because identifying perceived risk is difficult for most people, frame risk in terms of the unknowns that may prevent them from achieving their goals. For example, ask, “What are your assumptions?” instead of “What are your risks?”

2.Analyze—analyzing risk based on established criteria. Estimate the probability and consequence of a risk, and evaluate the risk with respect to all the identified risks.

3.Plan—planning the next task to resolve a risk. Develop alternative strategies for risk resolution, and define a risk action plan for the selected approach. Establish thresholds that help you determine when to execute a risk action plan.

4.Track—monitoring planned thresholds and risk status. Compare thresholds to status to determine variances. Use triggers to provide early warning to implement the risk action plan while there is time to resolve the risk. Report risk measures and metrics.

5.Resolve—responding to notification of triggering events, executing the risk action plan, and reporting results of risk resolution efforts until the level of risk is acceptable.

Every risk management process has two primary components: assess and control [Boehm89]. Identify and analyze are process elements of risk assessment. Plan, track, and resolve are process elements of risk control. Risk control is a by-product of successful risk resolution.

2.3.2 Design a Scaleable Process

A standard risk management process is valuable because it serves as a reusable component for an organization and can save projects months of time spent writing procedures. One lesson that I learned by adapting a standard process to projects valued at $10 million to $100 million is that process is not “one size fits all.” Because projects vary in size, scope, and budget, we cannot expect that one standard process will fit every project. The requirement for flexibility in a reusable process component can be addressed by developing a minimum standard process required of the smallest project in the organization and designing tailoring recommendations that will scale the standard process to meet the needs of the largest project.

2.3.3 Define a Flexible Process

Projects should define a tailored version of the standard process to meet their individual needs. Tailoring allows for flexibility and for unique style. One project I worked on had biweekly videoteleconferencing risk management meetings. Another large project assigned a risk manager to coordinate the identified risks of several integrated product teams. Many innovative process improvements can be made by projects given a flexible process. The standard process is defined when it is described in terms of inputs, activities, outputs, and mechanisms that the project will use. The process definition is reviewed by the people on the project who are required to use the process. The peer review activity uses a checklist of quality criteria to evaluate the process. The process definition determines the effectiveness of the risk management process. There must be a feedback mechanism from the project’s process users back to the standard process maintainer, so that the process can be improved for the entire organization.

2.3.4 Execute a Cost-Effective Process

The risk management process must be cost-effective. As shown in Figure 2.3, a cost-effective process balances risk resolution and risk acceptance. We must weigh the cost of risk control against the expected loss without risk control. As risk increases, exposure to loss increases. Risk decreases with the cost of risk control. Even if a cost-effective risk management process exists, the risk and expected loss increase if it is not used. If it is to be cost-effective, a process that is used routinely must be streamlined. An optimal process will minimize total costs.

2.4 Infrastructure: The Organizational Foundation

Infrastructure is the organizational foundation that is needed to establish a risk-aware culture. Four infrastructure factors describe the enterprise support required to manage risk:

1. Organization—the way that we establish an environment that supports effective working relations.

2. Requirements—the minimum standard for projects.

3. Resources—the investment required to manage risk.

4. Results—the return on investment for managing risk.

The key points to remember regarding the risk management infrastructure are the following:

Senior managers’ values affect people’s behavior through policies.

Customers and senior managers set expectations for project behavior through requirements.

You resolve risks through the application of resources (e.g., budget, schedule, and staff).

You determine the business case for risk management through cost-benefit analysis.

2.4.1 Affect People’s Behavior through Policy

The company culture is a reflection of senior managers’ values, which are documented in policies that affect behavior. Policy is an administrative procedure or guiding principle designed to influence people to a particular course of action. For example, if senior managers believe that “you can manage what you can measure,” the project goals will be more quantitative than qualitative. A documented policy might require risks to be reported at project reviews—with a quantitative risk exposure, as opposed to a qualitative high, moderate, or low rating. Organizational leaders should not set the expectations for risk management practices too low. With a simple policy in place to address risk in a responsible manner, people will generally comply with the established procedure.

Figure 2.3 An optimized risk management process. Overall cost and risk are minimized through cost-effective risk resolution. Without attention to software risk, the exposure to risk increases.

Once a policy to manage risk is in place, a risk-aware culture can be developed in several ways. Infrastructure is developed top down by managers, who provide leadership and resources for risk management; bottom up by empowerment of the workforce and rewards for positive results; and sideways by the definition of roles and responsibilities in the organization chart—the horizontal relationships. These relationships may not be defined explicitly in the organization chart, but they usually exist between software engineering and other engineering disciplines (systems, hardware, and test). Integrated product teams (IPTs) help to define the horizontal relationships within a single IPT, but be sure to define how IPTs work together to resolve interrelated risk. A policy for risk management is presented in Chapter 9.

2.4.2 Set Expectations for Project Behavior

Through requirements, customers and senior managers set the expectations for project behavior. Requirements for risk management are often defined by the contract and statement of work, which specify deliverables such as a risk management plan. Systems engineering standards that specify risk management include IEEE 1220 and EIA 632, Processes for Engineering a System.³ Software development standards that address risk include DoD’s MIL-STD-498, ISO 9000-3, and the IEEE Software Project Management Plan.

³ Development of EIA 632 was accomplished as a joint project of the Electronic Industries Association (EIA), the Institute of Electrical and Electronics Engineers (IEEE), and the International Council on Systems Engineering (INCOSE) [Martin97].

MIL-STD-498 is a standard for software development and documentation that replaced the document-driven standards DoD-STD-1703, DoD-STD-7935A, and DoD-STD-2167A, which required contractors to document and implement procedures for risk management but was silent on when to perform risk management. MIL-STD-498 is an improvement over its predecessors because it specifically states that risk management is performed throughout development through identification, analysis, and prioritization of technical, cost, and schedule risk areas. MIL-STD-498 states that strategies for risk management must be developed, recorded, and implemented [DoD94].

The U.S. commercial version of MIL-STD-498 is EIA/IEEE J-STD-016 Software Development. The DoD plans to incorporate MIL-STD-498 into an international commercial standard, ISO/IEC 12207 [McPherson95]. The U.S. implementation of this international standard for software life cycle processes is IEEE/EIA 12207. These improved standards preserve the heritage of risk management as a software development requirement.

The ISO 9000 series of standards is a set of documents, promulgated by the International Standards Organization (ISO), a worldwide federation of national standards bodies, that specifies quality system requirements. The ISO 9001 standard applies to software. ISO 9000-3 is a guideline for the application of ISO 9001 to the development, supply, and maintenance of software; it is an international standard for quality management and quality assurance of software. The guidelines are intended to suggest controls and methods for producing software that meets requirements by preventing nonconformity at all stages of development. If your software company has a requirement for ISO conformance, then you have a requirement for risk management. Four guidelines specifically address risk:

1. Corrective action. The supplier should establish, document, and maintain procedures for investigating the cause of nonconforming products and the corrective action needed to prevent recurrence. It will initiate preventive actions to deal with problems to a level corresponding to the risks encountered.

2. Contract review. The supplier should review each contract to ensure that possible contingencies or risks are identified.

3. Development plan. The development plan should divide the work into phases, and identify and analyze the potential problems associated with the development phases and the achievement of the specified requirements.

4. Design reviews. The design or implementation process should not proceed until the consequences of all known deficiencies are satisfactorily resolved⁴ or the risk of proceeding otherwise is known [ISO91].

⁴ This instruction from ISO is confusing because we cannot resolve a consequence. I believe the intent is to resolve risk to an acceptable level.

The Institute of Electrical and Electronics Engineers (IEEE) standard for software project management plans was approved by the American National Standards Institute (ANSI). Risk management is a managerial process identified as follows in the Software Project Management Plan (SPMP):

This subsection of the SPMP shall identify and assess the risk factors associated with the project. This subsection shall also prescribe mechanisms for tracking the various risk factors and implementing contingency plans. Risk factors that should be considered include contractual risks, technological risks, risks due to size and complexity of the product, risks in personnel acquisition and retention, and risks in achieving customer acceptance of the product. [IEEE88]

2.4.3 Apply Resources to Resolve Risk

Budget, schedule, staff, and other resources must be applied to resolve risk. Implementation of risk action plans may require funds for resolution approaches, such as market research or the use of redundant system components. Use of scarce resources is likely to cause additional stress to the project budget and schedule. Applying risk management helps to make difficult trade-offs to allocate resources effectively. For example, risk assessment findings have shown a correlation between funding risks and inefficient utilization of people. As one project found out, using staff time to define roles and responsibilities clearly was a small price to pay for the increase in efficiency on the project.

2.4.4 Analyze Risk Management Costs and Benefits

The business case for risk management is based on cost-benefit analysis. If the cost to develop a risk management process is spread over ten projects, then benefits from process reuse can be estimated by the amount of time saved. Savings are measured in resources of time, money, and staff not expended on nine of ten projects. Cost is measured by the number of person-hours expended to develop the process. Return on investment (ROI) is the ratio of savings to cost that indicates the value provided.⁵ The business case to develop a standard risk management process in the above example is justified at 10 to 1 ROI.

⁵ Accountants define ROI as a ratio of net income to total assets.

Without ROI data, senior managers must rely on testimonials of project managers and staff to judge the perceived benefits of risk management. Reliance on testimonials is built on trust and perception. Trust will erode over time unless perceptions are validated by ROI data. Chapter 8 presents a definition for measuring effectiveness of the risk management process: ROI_(RM). Several uses of ROI _(RM) are described in Chapter 18. Case studies in Chapters 22 and 23 report ROI using this standard measure.

2.5 Implementation: The Project Execution

Risk management can be implemented by steering committees, senior executives, business area teams, proposal teams, middle management, line management, or individuals. Implementation, as I discuss it in this book, is how a particular project executes risk management. The implementation factors of risk management plan and methodology describe how the risks are managed. The risk management plan maps resources to risk management activities to satisfy project requirements. Methodology is a set of underlying principles and methods particular to a branch of knowledge. Methods include the mechanisms, techniques, and automated tools that support the risk management implementation. The key points to remember regarding the risk management implementation are the following:

Success begins with a high-quality plan.

Projects have a unique personality that their methods reflect.

2.5.1 Develop a High-Quality Risk Management Plan

Risk management implementation depends on the people in the project given responsibility and authority to execute the risk management plan. Success begins with a high-quality plan. The procedures for performing risk management on a project may be embodied in a documented risk management plan that describes the approach to managing risk on the project. The best approach is proactive, integrated, systematic, and disciplined.

Proactive. Performing proactive risk management means taking the action required to assess and control risks to prevent problems on software projects [Hall95]. Getting the help you need to assess and control risks also is proactive. Projects beginning to incorporate risk management methods may need a facilitator for independence and motivation.⁶ The independence provides an objective view of the project without attribution or blame to individuals whose areas of the project are inherently risky. Motivation is provided to the project in two ways: the facilitator has the knowledge to support a discussion of risks to assess risk situations, and his or her periodic appearance serves as a catalyst for use of risk management to progress toward project goals. You probably need the help of a facilitator when one of the following conditions exist:

⁶ I recommend a facilitator when you lack the time or ability to do it yourself. Lack of ability may be either low skill level or the inability to be impartial.

Lack of time. Most team members are too busy handling current problems.

Low ability. Most team members are not confident assessing risk.

High attribution. Most individuals are not comfortable discussing risk.

Integrated. Risk management is integrated in a project when it is implemented as a part of the way that a product is produced. Risk is neither more nor less important than work but, rather, a part of the remaining task.⁷ There is no “risk season” [VanScoy92] or a separate team to perform risk management. Risk management is integrated by distribution into routine project activities.

⁷ Risk exists in our work—our past, present, and future efforts. Past effort may contain the risk of misunderstood requirements, present effort may contain the risk of false assumptions, and our plan for future effort may contain the risk of uncertainty.

Systematic. It is not enough to identify risk; you must follow through with risk resolution, or risks will turn into problems. Projects that emphasize risk assessment with no follow-through for risk control will have an unbalanced approach that does not systematically reduce risk. To create a more balanced approach, spend 20 percent of your time on risk assessment and 80 percent of your time on risk control. It is better to resolve a few risks than it is to identify many risks but do nothing with the risk information.

Disciplined. A complete strategy is based on the six disciplines of the 6-D Model described in Chapter 1: Envision, Plan, Work, Measure, Improve, and Discover. Each discipline has principles and methods that you can use to develop an effective risk management approach. The developmental path for an individual’s acquiring the skills to master any discipline is through unconscious inability, conscious inability, conscious ability, and unconscious ability. The developmental path for organizational learning is through initial contact, awareness, understanding, trial use, adoption, and institutionalization [Conner82].

2.5.2 Choose Methods That Reflect a Project’s Personality

The methodology, the means for implementing the risk management process, encompasses specific principles, methods, and tools. Principles are the underlying rules used by those who work in a discipline (e.g., diversification). A method is a technique or other systematic procedure—for example, the mechanisms that implement the process (e.g., risk management form). Tools include the automated mechanisms used to execute risk management efficiently (e.g., risk database). Methods reflect the personality of the project because they are how projects choose to implement the process. Methods are the means to the end; as such, they present a variety of choices that may achieve similar results. The methods may be ad hoc or structured, simple or complex, team oriented or not, depending on how the project chooses to conduct business. The style of the project may mirror the individuals who constitute the project or may conform to the customer’s style.

2.6 Summary

In this chapter, I discussed a success formula for managing software risk and described the major factors that affect risk management capability. The success formula for managing software risk is P²I²: people, process, infrastructure, and implementation.

People participate in managing risk by implementing the risk management process according to the risk management plan. As long as people engineer software systems, they will be a critical factor in communicating the issues, concerns, and uncertainties in their work that translate to risk.

Process transforms uncertainty (the input) into acceptable risk (the output) through risk management activities. Process is a major factor in risk management capability, because it describes the steps to predictable risk management results.

Infrastructure is the way that the enterprise requires the use of risk management on projects, such as by establishing a policy and standards. It is a major factor in risk management capability because it establishes the culture that supports the use of risk management.

Implementation is the methodology and plan used to perform risk management on a specific project. It is a major factor in risk management capability because it assigns to the project the responsibility and authority to execute the plan.

I used a force field analysis to show how to overcome the barriers to risk management adoption by identifying the positives and negatives of adopting risk management:

List the driving forces (the reasons for adoption).

List the restraining forces (the barriers to adoption).

Reinforce the driving forces (the motivation).

Eliminate the restraining forces (the effort).

The risk management process is necessary but not sufficient; it takes more than a risk management process to manage risk. Process is shelfware without project implementation. Implementation may not succeed without an organizational infrastructure that supports communication about risk. People are the common denominator in each dimension: process, implementation, and infrastructure. Ultimately, people manage risk.

2.7 Questions for Discussion

1. What are five ways that you could increase your participation, ability, and motivation to manage risk? Do you think this increase in capability to manage risk would change how you work? Explain your answer.

2. Compare and contrast education, training, and experience in risk management. Provide an outline for a lecture on the history of risk management, a hands-on seminar to learn a risk analysis tool, and a meeting agenda for managing software development risk.

3. List your top three barriers to managing risk. Describe a plan to reduce or eliminate each of these barriers. What test criteria would you use to evaluate your success?

4. List your top three reasons for adopting risk management. Describe your reasons in terms of their effect on quality, productivity, cost, and risk of software development.

5. You are the technical lead for a commercially available requirements management tool. Your supervisor has come to you for a make-or-buy decision: In the next tool release, should you develop an object-oriented database in-house, or use an existing third-party object-oriented database package? Use a decision tree to diagram decision, chance event, and outcome nodes. Discuss the parameters of this decision from three perspectives: risk averse, risk seeking, and risk neutral.

6. Do you agree that every risk management process has two primary components: risk assessment and risk control? Discuss why you do or do not agree.

7. Describe how to develop an infrastructure that would support a risk-aware culture from three perspectives: top down, bottom up, and sideways.

8. Develop the business case for risk management. Provide a hypothetical cost-benefit analysis. Was the return worth the investment? Discuss why it was or why it was not.

9. What are the relationships among the four major factors of the P²I² success formula for managing risk? Discuss the dependencies among the factors.

10. Give ten reasons that it is important to involve people at all levels of the project in managing risk. How could you ensure the participation of people at all levels?

2.8 References

[Boehm91] Boehm B. Software risk management: Principles and practices. IEEE Software, 8(1):32–41, 1991.

[Boehm89] Boehm B. IEEE Tutorial on Software Risk Management. New York: IEEE Computer Society Press, 1989.

[Brassard94] Brassard M, Ritter D. The Memory Jogger II. Methuen, MA: GOAL/QPC, 1994.

[Conner82] Conner D, Patterson R. Building Commitment to Organizational Change. Training and Development Journal, April, pp. 18–30, 1982.

[Curtis95] Curtis B, Hefley W, Miller S. People Capability Maturity Model. Technical report CMU/SEI-95-MM-002. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1995.

[Davis88] Davis, W. The Best of Success. Lombard, IL: Great Quotations, 1988.

[DeMarco87] DeMarco T, Lister T. Peopleware: Productive Projects and Teams, New York: Dorset House, 1987.

[DoD94] Department of Defense. Software Development and Documentation. MIL-STD-498, AMSC NO. N7069, December 1994.

[Hall95] Hall E. Proactive Risk Management Methods for Software Engineering Excellence. Doctoral dissertation, Computer Science Department, Florida Institute of Technology, Melbourne, FL, April 1995.

[Humphrey89] Humphrey W. Managing the Software Process. Reading, MA: Addison Wesley, 1989.

[IEEE88] ANSI/IEEE. IEEE Standard for Software Project Management Plans. ANSI/IEEE STD 1058.1-1987. October 1988.

[ISO91] American National Standards Institute International Standards Organizations. Quality Management and Quality Assurance Standards. ISO 9000–3, 1991.

[Keirsey84] Keirsey D, Bates M. Please Understand Me. DelMar, CA: Prometheus Nemesis, 1984.

[Martin97] Martin J, et. al. EIA Standard Processes for Engineering a System. Electronic Industries Association, EIA 632, 1997.

[McPherson95] McPherson M, et al. Guidelines for Successful Acquisition and Management of Software Intensive Systems: Weapon Systems, Command and Control Systems, and Management Information Systems. Hill Air Force Base, UT: Software Technology Support Center, February 1995.

[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.