Common Risks

In the process of launching our bank, we went through lots of successful and unsuccessful project implementations; there are couple of reasons why some of these projects were unsuccessful, failed or partially successful. Absence of experienced resources, unclear requirements and unreasonable time schedules were the main reasons for unsuccessful software and business projects within my organization.

Gathering requirements and understanding them is the most common overlooked risk, unclear requirements is one of the most critical software risks which emerges from many factors such as: not enough knowledge about the needed solution, who gives the requirements is usually not the end user which makes it on a very high level, Business analyst didn't understand the requirements clearly, no requirements review from the quality assurance and customer, not enough analysis for the requirements and poor communication between the business analyst and the developers. To mitigate the impact of this risk, I would reduce the likelihood of unclear requirements to occur (Bannerman, 2008). I do this by presenting a quality assurance person, along with the business analyst, during the requirements gathering sessions to review the documented requirements and to ensure that they are written according to the customer needs, the customer has to review the requirements and approve it, at certain milestones during the development, the customer has to be involved in the review of the first releases of the software to fix any wrong features at early stages. There is no way to avoid unclear requirements, as there will always be a room for misinterpretation of the requirements, of lack of understanding for some.

Another common risk we face is that the customer/end user wants the application to have every possible feature: The customer (or the end user) usually needs a software to relief their pain or to replace an existing obsolete software, and that software has to have all possible features even the most trivial ones just in case it might be needed in the future, this therefore increases the complexity of the software and affects the time needed to finalize the project. To mitigate this risk, I would document the requirements, then explain to the customer the impact of the nice to have features on the code and project time lines which impacts the delivery of the project, and if they agree on the impact then a change request has to be developed and approved, by this we transfer the risk to the customer, if they don’t approve it, we escalate to the management. In order to avoid this risk, features are divided into major, good to have, and nice to have, the nice to have features are put on a wish list and if within the specified time frame there's time to develop them then they will be considered.

Another common risk is time estimates are not precise, the main cause for this risk is that the resources that do the planning are not the same resources that actually do the coding. To mitigate this risk, we add a buffer in the time estimates given by the team leader. And to avoid this risk, the project manager has to define the project team as a first step, get the estimates from the same resources that are going to develop the software and add a buffer to these estimates.

References:

Armour, P. (2005), 'Project Portfolios: Organizational Management of Risk', Communications of the ACM, 48, 3, pp. 17-20, Computers & Applied Sciences Complete, EBSCOhost, [Online], Available from: http://web.ebscohost.com.ezproxy.liv.ac.uk/ehost/detail?sid=2becee82-5b18-45a1-b7c1-8bbeca42928f%40sessionmgr10&vid=1&hid=19&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=iih&AN=16390580

(Accessed 16 April 2011)

Bannerman, P. (2008), ‘Risk and risk management in software projects: A reassessment’, Journal of Systems and Software, Volume 81, Issue 12, Best papers from the 2007 Australian Software Engineering Conference (ASWEC 2007), Melbourne, Australia, April 10-13, 2007, Australian Software Engineering Conference 2007, pp. 2118-2133, ISSN 0164-1212, DOI: 10.1016/j.jss.2008.03.059, [Online], Available from: http://www.sciencedirect.com/science/article/B6V0N-4SBSDDK-2/2/3664c09f725897dd90a36b4752b2e5ce

(Accessed 16 April 2011)

Costa, H., Barros, M. & Travassos, G., (2006) ‘Evaluating software project portfolio risks’, Journal of Systems and Software, Volume 80, Issue 1, January 2007, pp. 16-31, ISSN 0164-1212, DOI: 10.1016/j.jss.2006.03.038, [Online], Available from: http://www.sciencedirect.com/science/article/B6V0N-4K128V5-3/2/c33d2b09593d857e06c434889323d676

(Accessed 16 April 2011)