COSC 6351 Term Paper (Word file)

Zhibin Ma

Risk Management for Software Project

Introduction

Risk management is very important for a software project. When software engineers making software project plans, they usually assume that everything will go exactly as planned. However, surprises are often arises here and there. Some people think that surprises are unavoidable because of the creative nature of software. Others are seeking resolutions to reduce surprises. Research shows that risk management is becoming recognized as a best practice in the software industry for reducing the surprise factor. Although future cannot be predicted with certainty, risk management could minimize the potential problems. Software Risk Management is a “proactive approach for minimizing the uncertainty and potential loss associated with a project” (Jim Mundell). The primary goal of risk management is to provide insights to support decision-making.

What Is Risk

According to Jim Mundell’s definition, risks are “those factors that may prevent the attainment of a set goal [9]. In software engineering, risk is a measure of the inability to achieve overall program objectives within defined cost, schedule, and technical constraints. It has two components: (1) the probability of failing to achieve a particular outcome and (2) the consequences of failing to achieve that outcome”. For example, a common risk for many software projects is that they fail to deliver acceptable systems within schedule and budget.

Common Software Risks

It is very important to analyze software risk from the beginning till end of software projects. Otherwise, projects probably will not carry on well as planned. Software projects risk could occur very often. Following are some of the risk examples from Mr. Raymond Mille.

· Project itself

Project risks include inadequate configuration control, cost overruns and poor quality. Poor quality means the software either does not work very well, or it fails in operation repeatedly.

· Commercial software risks

A finished project may have lower user satisfaction. Lower user satisfaction means the product has low quality, functions inadequately, and has complex structures. Users are also displeased by excessive utilization of disk space or other hardware components requirements by the software.

· Military software risks

Military has unique requirements for software. The most common risks are excessive paper work and long schedules. Research shows that more than fifty percent of software project expenses are paperwork cost. Long schedules will more often cause software project no longer useful when it is finished.

Software Risks Factors

In order to take affirmative risk control, it is necessary to realize what the risk factors are.

Capers Jones has identified the top five risk factors that threaten projects in different application sectors [4]. Table 1 illustrates those factors, and the approximate percent of projects to which they apply, in the management information systems (MIS) and commercial software sectors. (See exhibit 4 Table1)

Following are several typical risk categories and risk items identified by Karl E. Wiegers [10]. (See Exhibit 5)

· Requirements issues

Many products meet uncertainty around the product’s requirement [10]. Risk factors occur when project team lack product vision, or requirement changes rapidly.

· Dependencies issues

Dependencies of outside agencies or factors increases software risk in many cases. It is usually very hard to control these external dependencies, so mitigation strategies may involve contingency plans to resolve this problem.

· Management issues

In most cases, the project manager writes the risk management plan. If he doesn’t want to show his shortcomings, it may make it harder for projects to succeed. Clear roles and responsibilities, and defined project tracking processes, can address some of these risk factors.

· Lack of knowledge issues

If software technologies are changed rapidly, and non-experienced staff increases, the project teams may not have the enough skills to finish the products successfully. Increasing the trained people is the best way to resolve this problem.

Two Steps for Risk Management

According to Richard Fairley, quality assurance activities do pose a direct or indirect risk to the software development process. Current software risk management has been adapted from concepts, practices, and principles, which has been successfully used within other engineering and manufacturing arenas. Richard lays out a seven-step risk management process. I reduce them to a six-step process, and put them into two primary steps, each having three subsidiary steps.

The first step is risk assessment, which consists of:

• Risk identification. Risk identification is to identify project, product and business risks. Risks to a software project must first be identified. One way of identifying software project risks is to follow the most common risk types. (See exhibit 1) The other way is using a questionnaire such as the SEI Taxonomy-Based Risk Identification Questionnaire. These questions concerning risks should be periodically reviewed; this should allow for the identification of most risks in a software project. (See exhibit 2)
• Risk analysis. The purpose of analysis is to convert the data into decision-making information. Analysis is a process of examining the risks in detail to determine the extent of the risks, how they relate to each other, and which ones are the most important. (See exhibit 2)
• Develop strategies to mitigate identified risks. According to Richard, Risk mitigation involves two types of strategies, which are “Action planning” and “Contingency planning”. Action planning addresses risk that can be mitigated by immediate response. For example, the action plan could provide for hiring experienced personnel to resolve the risk of insufficient experience with new hardware architecture. On the other hand, “contingency planning addresses risks that require monitoring for some future response should the need arise.”(See exhibit 3)

The second step is risk management. This step, used to bring these risk items under control, consists of:

· Risk monitoring. As a project proceeds, some risks will be eliminated, but some new risks may also occur. Some risk mitigation actions will work well, but some may not work and new action will need to be taken. As a project proceed, priorities will change and new risk management planning will need to be undertaken. Therefore, the projects progress towards resolving risk items or taking corrective action should be tracked. (See exhibit 2)

• Invoke a contingency plan. A contingent plan is invoked when a quantitative risk indicator crosses a predetermined threshold. For example, if a project team cannot solve the problem within a specified period, like two weeks, they must invoke a crisis-management plan.
• Manage the crisis. For some reasons, if the contingent plan fails, there must have some other plan to reevaluate the project or to cancel the project.

Conclusion

Risk management control is just beginning. Software engineers are still working on how to measure risk factors and integrated them into project planning. Risk check and the two-step risk management method can be used with many other techniques to reduce project risk, so that potential problems can be identified, controlled, or avoided before they occur.

Bibliography (See exhibit 6)

Attachment

Exhibit 1: Risk Types

Exhibit 2: Some Details Information

Exhibit 3: Risk Strategies

Exhibit 4: Table 1. Most Common Risk Factors for Various Project Types

Exhibit 5: More Details of Software Risk Factors

Exhibit 6: Bibliography