Faculty of information technology industry (FITI)
IAS 3133 IT PROJECT MANAGEMENT
Journal Review on
An empirical analysis of risk components and performance on software projects
Prepared for:
Lecturer :En.Zulkefli b Mansor
Prepared by :
Muhammad Fariq b Abdul Halim
4092012511
Bachelor of Information Technology (Supply Chain Management) (Hons)
2/2011/2012
An empirical analysis of risk components and performance on software projects
Introduction
This paper explores the relationships between software risks and their impact on project performance.
Many of software projects were unable to deliver on schedule, within budget, and with the required functions. As software development is a highly complex and unpredictable activities the organizations invest substantial resources and effort on software development, controlling the risks associated with software projects becomes crucial (Kumar, 2002).There are two basic components which is probability of occurrence and impact on project performance that have to understand to developing an efficient and suitable risk management strategy (Boehm, 1991).The probability of occurrence is difference of software risk and its impact on project cost, schedule and quality is also different. This paper shows the findings from an empirical study base on 115 software projects on analyzing the probability of occurrence and impact of the six dimensions comprising 27 software risks on project performance.
These risks are classified into six dimensions namely, user, requirement, project complexity, planning and control, team, and organizational environment. MANOVA and Two-Step Cluster Analysis methods are to analyze a data set from ‘115’ historical software.
Discussion
First is to determine the relationship of the probability of occurrence and impact in six risk dimensions.
The results of the MANOVA indicated that the probabilityof occurrence and composite impact of the softwarerisks of the six risk dimensions were significantly different. A higher mean for a risk dimension indicates a higher possibility of occurrence or degree of influence. The baseline threshold, which was computed by averaging the six risk dimensions for each risk component, is a measure of the comparison criterion. Risk exposure was computed by multiplying the probability of occurrence with the composite impact (Boehm, 1991).Two dimensions of software risks occur more frequently than the others. They are followed by the dimensions of ‘‘team’’, ‘‘planning and control’’ and ‘‘user’’ risk dimensions. It would be better for the project managers to adopt a strategy that reduces its probability of occurrence rather than lowers its degree of impact on the project performance.
Secondly, the relationship between risk dimensions and impact. The concept of ‘‘organizational environment’’ is more abstract and broader and hence, the project managers had difficulty in distinguishing the degree of differences from the various impacts.
This reveals that if the project managers do not employ the appropriate risk management strategy for each of the risk dimensions, the efficiency or possible benefits from the software risk management will be negatively affected.
The third is patterns in risk dimensions across the levels of project performance. This finding provides empirical evidence that software risks decrease the degree of project performance (Jiang and Klein, 2000; Wallace and Keil, 2004).The difference betweenthe regions of low-performance and medium-performancesoftware projects is much larger than the differencebetween the medium-performance and the high-performancesoftware projects.The result suggests that managing the ‘‘requirement’’ risks is critical to achieving the best project performance because even the high-performance projects still have a high degree of the requirement risk dimension. There are four important findings which is successfully managing the ‘‘requirement’’ risk is a basic requirement for achieving the desired software project performance, secondly project complexity, thirdly, this suggests that the medium and low-performance projects need to carefully manage the ‘‘planning and control’’ risk so that they can have chances. Lastly, this suggests that notaddressing well the risks associated with the development team can negatively affect project performance.
Lastly is a list of the top 10 risks. To determine the top 10 risks which lead to failure in software projects, the risk exposure of all the risks within the six dimensions were computed by multiplying the value of probability of occurrence with the various degrees of composite impact. The top 10 risk is continually changing system requirements, system requirements not adequately identified, unclear system requirements, lack of an effective project management methodology, incorrect system requirements, poor project planning, inadequate estimation of required resources, project involved the use of new technology, project progress not monitored closely enough, corporate politics with negative effect on project. (Boehm, 1991; Mursu et al., 2003; Wallace and Keil, 2004)
Conclusion
Project managers have to understand the nature of software risks to achieving effective software risk management requires. To develop a better risk management strategy, project managers can refer to the information about the probability of occurrence and impact of software risks on project performance.
This empirical study considered risk information on 115 software projects. The results indicate that a positive correlation does not exist between the probability of occurrence and impact among the six risk dimensions. The relationship between software risks and project performance was also examined in the high, medium, and low-performance projects. The results show that the ‘‘requirement’’ risk dimension is the principal factor affecting the project performance. Other than that, one of the ways to improve projectPerformance is by properly planning the development activities and reducing the project complexity. If the project manager is unable to effectively manage the requirements of the whole project life cycle, and does not well-plan nor monitor the software risk management plan, the software projects is likely to perform poorly. The performance of the software projects could also benefit from exploring the relationship between risk components and some important attributes of software projects such as the type of software systems and project duration.
References
Kumar, R., 2002. Managing risks in IT projects: an options perspective.
Information and Management 40, 63–74.
Boehm, B., 1991. Software risk management: principles and practices.
IEEE Software 8 (1), 32–41.
Jiang, J., Klein, G., 2000. Software development risks to project effectiveness.
The Journal of Systems and Software 52, 3–10.
Wallace, L., Keil, M., 2004.Software project risks and their effect on outcomes.
Communications of the ACM 47 (4), 68–73.
Mursu, A. et al., 2003. Identifying software project risks in Nigeria: an international comparative study. European Journal of Information
Systems 12 (3), 182–194.