Introduction
Software projects are complex technological projects in a way that each project is unique and thus has its own risk. This paper tries to find if risk management best practices as defined by project management frameworks and literatures are sufficient in real world projects. The report starts with defining software projects and risk management. In second section the paper tries to answer if risk management policy defined in literature is sufficient in practice and if software managers should try to implement or not. The last section takes real life case study of miss-managing risk in software project and its implication.
In the end the paper tries to find balance between literary view of risk management with practical view by software developers and managers.
Software Projects and Risk Management
Software project is the work undertaken to specify, design, develop, test and implement a new software solution for the client (internal or external). Unlike any other industrial projects, software projects are unique in the sense that it is difficult for the end user to explain their requirement (Cadle & Yeates, 2008).
As with any project, there are risks associated with software project too and is defined by L Wallace et al. (2004) as circumstances that can create a serious threat to the successful completion of software project. Project management best practices, such as PMBOK, SEI-CMMI and PRINCE2 provides framework to identify and analyse risks to the project. In addition, as par Paul Bannerman (2008) “risk management is not only about identifying and assessing risk but also being able to respond quickly and effectively to realised threats as they arise”.
Does Risk Management Policy Matter?
Software project management best practices require that for successful completion of project, potential risks should be identified before the start of the project. All such risks are maintained in risk register and probability of its occurrence is estimated. However, Raymond (Yeh, 1991) strongly argues that because of complexity of software risk, they resemble more to ‘wicked problems’ and are difficult to define until they are nearly solved. Project management best practices do not work well for wicked problems as requirement cannot be defined until the system is ready and deployed.
Another problem with maintaining risk register is that risk occurrence/factor need to be identified and only way to do this is by using probability theory, which in turn assumes that risk assessor or project manager have previous sets of data for risk and probability of its occurrences can be quantified. However, statistical data derived from probability matrix is insignificant and cannot be relied upon as software projects are unique (Pender, 2001).
Some of the framework demands from project managers that they should identify and control these factors to reduce the chance of project failure. Not all risks can be identified let alone managed beside, it is not possible to envision every possible kind of threat and prepare necessary steps to eliminate or contain the risk. Furthermore, panic reaction by the client means in practice, risk assessor may choose not to list/identify all the risks to the project to the client during early phases of the project (Schmidt et al., 1999).
Research by Schmidt et al. (1999) and Kutch & Hall (2010) shows that project team members are not comfirtable reporting possible risk to project exectutive fearing they will be blamed for the situation (shoot the messanger attitude by higher management).
The competition of following best practices, resulted in more time being spent on project planning, system designing, tracking & managing risk than actually writing the software code. To avoid this time consuming task, many software managers try to delibratly ignore the risk considering it irrelevant to the project or chose not to report in their periodic project meetings (Kutsch & Hall, 2010). Managers also try to hide the risk from the client in order to get the software project. If they bid for the project showing that there are number of risks to the completion of the project, client may refer to award the contract to other party (or outsource to other IT firms, if project is internal).
Furthermore, research by Magne Jørgensen (2010) suggests that spending more effort on risk identification by software developers leads to more over-optimistic estimates and higher over-confidence in the estimation accuracy and success probability of software project. In practice, software developers spending time thinking about the possible risk to the project, utilize part of their time analysing technical viewpoint and how to resolve the possible risk. Moreover, software developers tend to give estimates based on how much time they will take to deliver the project. Those one’s who do not get enough time to analyse the risk tend to add “cushion” period or contingency factor to the total estimates anywhere between 15% to 20% extra time on top of what was estimated for ideal conditions.
What If Risk Is Not Managed?
Learning and Skills Council (LSC), a non-departmental body in UK was responsible for planning and funding further education. LSC had six separate systems for delivering learner support. In 2007 contract was awarded to Liberata Consortium to combine all six systems into a single Learning Support System (LSS) so as to reduce cost and provide an enhanced service. The consortium included Liberata, Perot Systems and Logica CMG. These consultancy firms were competitors outside of this consortium resulting in mistrust, lack of transparency and hidden agendas during the project.[1] This made success of a risk management process vulnerable as openness and cooperation is a must between all participating parties (Schmidt et al., 1999).
Risk to the project started well before the start of the project when LSC failed to follow proper risk management strategies while awarding the contract. For example LSC did not considered the operational and reputational risk as possible risk to the project and focus was given to financial risk alone (Ighodaro, 2009). Failing to understand and manage software project risk lead to cost and schedule overruns, unmet user requirement and in the end result was that LSS never got developed and delivered. This risk management failure prompted government to close down LSC (BBC News, 2008). This case study is just one of several examples where cost of not managing risk is too high to neglect.
Another study by Boehm & Basili (2005) have shown that software developers spend about 40 to 50 percent of their time on avoidable rework, fixing the bugs caused due to error in requirement specification. Moreover, the cost of fixing an error, after software has been delivered, can be 100 times as high as it would have been during the development stage (Boehm B. , 1987). Figure 1 below give a picture of the cost of the risk as project progresses. If risk is realised at the deployment stage, project manager has responsibility to correct the design, code development, test plan and have to redeploy the software, which adds to the cost of the project in terms of both financial and schedule overrun.
Figure 1 Growing cost of fixing bugs
The case study of LSC project and research by Boehm (1987), Wallace et al. (2004) shows that cost for not considering Risk Management beforehand is too high.
Conclusion
Most of the research and academic studies points that risk identification and management is task of project managers. It is expected from them to identify and control the risk factors to reduce the chance of any failure. However risk identification in practice should be considered responsibility of all the stakeholders in the project right from business analyst, sales, and project manager to software developers. Even team members, who are not directly responsible for managing the project, should be able to report the risk to project manager instead of waiting for risk to become crisis (Schmidt et al., 1999).
As we have seen earlier, most risk management processes rely on probability theory to identify the level of risk project might be facing. As par Pender (2001), “such reliance on probability theories can mask other aspects of incomplete knowledge and can lead to a false sense of accuracy and precision”.
Nevertheless, risk management is a critical part of any software project, and is particularly crucial in large projects where there is high uncertainty latest technology is involved (for example software development based on new operating system (OS) released by Microsoft is a risk to project as the OS not been tested and yet to be proven). Risk should be identified and managed by all team members at each stage of the project. The cost of not managing risk beforehand could be expensive or disastrous for project and in some cases even to the company. Thus the cost of identifying and keeping watch on events which may or may not develop into risk is tolerable. In addition to following the checklist to manage risk, it would help project managers or risk assessors if they use Risk Sharing or Team Risk Management Principles (Higuera et al., 1994) to manage risk which seeks involvement from all stakeholders.
To conclude, project management best practices ask to identify risk however they does not help in identifying the risk factors (Wallace et al., 2004) still, risk management can prevent disastrous end to the project, avoid rework and provide preventive measures in case risk materialised. Therefore, project managers should follow risk management processes and also make conscious decisions to handle risk as and when it comes.
Bibliography
Bannerman, P. L. (2008). Risk and risk management in software projects: A reassessment. The Journal of Systems and Software , vol 81, pp. 2118-2133.
BBC News. (2008, March 17). £10.4bn skills agency scrapped. Retrieved September 24, 2010, from BBC News: http://news.bbc.co.uk/1/hi/education/7300852.stm
Boehm, B. (1987). Industrial Software Metrics Top 10 List. IEEE Software , vol 4, no. 5, pp. 84-85.
Boehm, B. W., & Basili, V. R. (2005). Software Defect Reduction Top-10 List. In B. W. Boehm, V. R. Basili, H. D. Rombach, & M. V. Zelkowitz, Foundations of empirical software engineering: the legacy of Victor R. Basili (p. 427). Springer.
Cadle, J., & Yeates, D. (2008). Project Management for Information Systems. Prentice Hall.
Higuera, R. P., Dorofee, A. J., Walker, J. A., & Williams, R. C. (1994). Team Risk Management : A New Model for Customer - Supplier Relationships. Pittsburgh: SEI-Carnegie Mellon University.
Ighodaro, C. (2009, Jaunary 28). LSC EMA Internal Review. Retrieved September 24, 2010, from readingroom.lsc.gov.uk: http://readingroom.lsc.gov.uk/lsc/National/11_-_2009_EMA_review.pdf
Jørgensen, M. (2010). Identification of more risks can lead to increased over-optimism of and over-confidence in software development effort estimates. Information and Software Technology , vol 52, no. 5, pp. 506-516.
Kutsch, E., & Hall, M. (2010). Deliberate ignorance in project risk management. International Journal of Project Management , vol 28, no. 3, pp. 245-255.
Pender, S. (2001). Managing incomplete knowledge: Why risk management is not sufficient. International Journal of Project Management , vol 19, pp. 79-87.
Schmidt, C., Dart, P., Johnston, L., Sterling, L., & Thorne, P. (1999). Disincentives for Communicating Risk: A Risk Paradox. Information and Software Technology , vol 41, no. 7, pp. 403-411.
Wallace, L., Keil, M., & Rai, A. (2004). How Software Project Risk Affects Performance: An Investigation of the Dimensions of Risk and an Exploratory Model. Decision Sciences , vol 35, no. 2, pp. 289-321.
Yeh, R. T. (1991). International Journal of Software Engineering and Knowledge. System Development as a Wicked Problem , Vol. 1, no. 2, pp. 117-130.
Comments