Theories of Risk Management in Software Projects

Risk Theories

High Failure

Project failure is an ongoing issue in software projects. During the relative infancy of computerized information systems in the 1960s, the difficulties of software project management and associated project fai lure were traced to inadequate system definition, improper vesting of responsibility, inherent complexity and fascination with technology to the detriment of meeting business needs (Gale 1968). Recent authors have concluded that software projects fail due to the inconsistent use of estimation metrics, complexity in both the design and implementation of software, insufficient experiences staff available to complete project tasks, inadequate project management (Glass 1998; Reel1999).
Another explanation for the high fai lure rates in software projects IS  » that managers are not taking prudent measures ta assess and manage the risks involved in  these projects » . But taking prudent risk management measures may be hindered by the complexity encountered when attempting to collect sufficient information to develop an informed judgment. It is rarely sufficient to simply ask other project participants for their views about a project’s status and its associated risks. Understanding a project’s risk characteristics requires reliable information.

Risks varies by project and activity

Many authors have made a well-reasoned case that risks vary by project and that risk management practices must accordingly deal with the specific detail in each case (Lister 1997). Project attributes that have discussed in the literature include Size (Moynihan 1997) and activity – maintenance vs. new development (Charette 1997).
Charette et al. (1997) argue that software maintenance risks differ in fundamental ways from new develops. The authors describe a project that endeavors to institutionalize risk management processes for an organization’s software maintenance processes. Key differences from new development risk management arise due to the software maintenance project’s need to sustain existing system availability while adding functionality. The authors believe maintenance can be an inherently risky activity because application systems may be decades old. Changes to existing software can be complicated by the existence of little or poorly kept documentation and software code that has been subj ected to lays of changed. Charette et al. (1997) cite one other difference between maintenance and new deve10pment. The typical risk reassessment cycle of six to eight weeks for new deve10pment projects was considered to infrequent to meet the demands caused by the respective and cumulative nature of software maintenance releases (Charette 1997).

Project Management in Managing Risk

The Project Management role is the first role in the software development pro cess that isn’t on the main line. The project manager isn’t a person doing « real work. » The project management role is one that is designed to help ensure that the software development process works as it is intended. The project management role works closely with the development management role in order to facilitate, encourage and prioritize the process.
The project management role is perhaps the most clearly defined role within the software development process due to the development of project management as a profession.
While the software industry is nascent, the project management industry is enjoying the advancement of a powerful organization in the Project Management Institute. They have assembled a guide to the body of knowledge for the project management profession that is often referred to as the PMBOK Guide. This organization has developed a widely recognized certification, Project Management Professional (PMP), which has both practical experience requirements as weil as traditional testing requirements.

Risk Management Theories

Risk management covers a range of topics and uses a portfolio of tools. The process of risk management covers risk planning, risk identification, risk assessment, risk response, and risk documentation.
Every human endeavor involves risk (Wider and Davis, 1998). A risk has two components-probability of occurrence and the effect of each occurrence. Projects are unique undertakings that involve a degree of uncertainty and are inherently risky (Chapman, 1998; Conroy and Soltan, 1998; Mak et al., 1998; PMI, 2000; Czuchry and Yasin, 2003). Risk in projects can be defined as the chance of an event occurring that is likely to have a negative impact on project objectives and is measured in tenus of likelihood and consequence (Wideman, 1992; Carter et al., 1993 ; Chapman, 1998). Risk management is an essential practice in achieving the successful delivery of SOFTW ARE projects (Tuman, 1993; Remenyi, 1999). More specifically, it consists of the fo llowing processes (Standards Australia, 1999):
Establish the context;
Identify risks;
Analyze risks;
Evaluate risks;
Treat risks;
Monitor and review;
Communicate and consult.

Management and Control Software Project Risks

It is generally agreed (Heemstra 1996; Lister 1997) that effective risk management software projects can help increase the probability of success. This can be accompli shed by providing projects managers with risk management approaches that enable managers to:
Cope with uncertainty inherent 111 software projects by identifying potential problems before they occur.
Improve the process of risk identification and mitigation definition with consistent application of these processes across multiple projects
Describe and address a project’s unique issues and circumstances.
Develop mitigation measures to address a project’s unique characteristics.
Justify the inclusion money and time in the form of contingency funds.
Provide cost rustication for proposed mitigation measures.
Demonstrate and address a divergence in opinion as to the risk that troubles any given software project.
Periodically review and update risk mitigation approaches.
Risk management underlies two components of software projects – management behavior and methodology. A risk manager’s behavior may be described as proactive, reactive or non-existent. Risk management methodoiogy encompasses systematic approaches to identifying and addressing risks. Together, behavior and methodoiogy can be used to expiain the capacity of software project teams to deal with both foreseen and unforeseen risks (Phelps 1996).

Risk Identification (PMBOK 2004)

Risk Identification determines which risks might affect the project and documents their characteristics. Participants in risk identification activities can include the following, where appropriate: project manager, project team members, risk management te am (if assigned), subject matter experts from outside the project team, customers, end users, other project managers, stakeholders, and risk management experts. While these personnel are often key participants for risk identification, ail project persolmel should be encouraged to identify risks.
Risk Identification is an iterative process because new risks may become known as the project progresses through its life cycle. The frequency of iteration and who participates  each cycle will vary from case to case. The project team should be involved in the pro cess so that the y can develop and maintain a sense of ownership of, and responsibility for, the risks and associated risk response actions. Stakeholders outside the project te am may provide additional objective information. The Risk Identification process usually leads to the Qualitative Risk Analysis process.
Alternatively, it can lead directly to the Quantitative Risk Analysis process when conducted by an experienced risk manager. On sorne occasions, simply the identification of a risk may suggest its response, and these should be recorded for further analysis and implementation in the Risk Response Planning process.

Table des matières

CHAPTER 1 INTRODUCTION 
1.1 General Content
1.2 Research Background and Motivation
1.3 Contributions and Benefits
1.4 Document Structure
CHAPTER 2 LlTERATURE REVIEW 
2.1 Risk Theories
2.1.1 High Failure
2.1.2 Risks varies by project and activity
2.2 Project management theories
2.2.1 General PM theories
2.2.2 project Management in Managing Risk
2.3 Risk Management Theories
2.4 Theories of Risk Management in Software Projects
2.4.1 Management and Control Software Project Risks
2.5 Risk Identification (PMBOK 2004)
2.5.1 Risk Identification: Toois and Techniques
CHAPTER 3 RESRARCH DESIGN AND METHODOLOGY 
3.1 Design of the Study and Research Method
3.2 Composition of the panels
3.3 Data Collection and Analysis Method
3.3 Results
3.3.1 Compared with Previous List
3.3.2 Rank of Risk Factors
3.3.3 Analyses of Results
3.4 Limits of Research
3.5 Future Research
CHAPTER 4 CONCLUSION 

Télécharger le rapport complet