Don't avoid risk in software development, manage it
- 03 June, 2009 14:51
<p>All software development contains inherent risks and to deny them invites disaster.
“Risk” is a very scary word. Most people view risks in a very negative light. Our whole society seems to be constantly encouraging us to avoid risk at all cost. A product represents a “health risk”. A service puts you at “financial risk”. If you drive this way you risk accident or death. Risk is bad, right?</p>
<p>But consider that huge companies like CitiGroup with assets in 2007 of more than US$2 trillion (Forbes Global 2000, March 2007) bases their entire business on managing risk. Why is something that is so bad for everyone else, so good for them? Why isn’t risk bad for them?</p>
<p>The truth is, anytime anyone undertakes any type of activity it involves risk. Business people and engineers (including software engineers) understand that risk is not actually good or bad – it just is. Risk rapidly becomes a real problem if we fail to recognise or plan for it. Managing and reducing risk is a discipline and good companies practice it on a daily basis.</p>
<p>One of the keys to successful software development projects is how the owner of the project and their development partners manage that risk.</p>
<p>It’s all about the thoroughness of their risk analysis and mitigation strategies and their vigilance in monitoring the risks associated with projects.</p>
<p>At Mitrais, we embrace a two stage approach to risk management. Significantly, we use exactly the same process for our internal projects as we do for client projects – because it works!</p>
<p>In the first or Risk Assessment stage, we identify the risks associated with a piece of work. We then make an assessment of the likelihood of each risk materialising and the impact that it would have if it did.</p>
<p>As a simple example, consider the risk to a project of a key staff member becoming unavailable through accident, illness or so on. So the risk is “key staff loss”. How likely is that to happen during a six month project? Experience tells us that it is may happen. What would be the impact? Perhaps the result would be that the team would be 30 percent less productive without that key player, so the impact could be up to 30 percent overrun on the project duration and cost – a pretty significant amount. By combining the likelihood (in this case medium) and the potential impact (high) we can see that this is a serious risk that needs management before it happens. That’s called the Risk Rating.</p>
<p>Now that we have identified and assessed the risk, what should we do? The next step in the process is Risk Management and Minimisation. One option we could use is called acceptance – we just accept that it might happen and hope for the best. This might be our only option for things we have no control over. Another option is called avoidance – we could double the size of the team so that every staff member has a full-time backup. But that invites other risks (inefficiency and boredom within the team) which we must also assess. The most common strategy is called risk mitigation. In mitigation we recognise the initial risk and put in place strategies that reduce its likelihood or impact (or, even better, both) until it becomes an acceptable risk. The amount of risk remaining after the mitigation strategy is called the Residual Risk.</p>
<p>In this case, one easy mitigation strategy would be to simply share key information between pairs of team members within the team. Should a particular team member be lost for a period, his or her counterpart could take the key role and the team can be back-filled at a lower level. The impact to the project will be minimal. We have effectively managed a severe risk down to an acceptable level by simply recognising and planning for it. It still may happen (so it is still a risk), but the impact if it does happen will be manageable.</p>
<p>Project risk management is, in fact, one of the core competencies encapsulated in the internationally recognised Project Management Body of Knowledge in which all Mitrais Project Manager receive formal training. It is also a competency against which project managers are assessed every year. An appointment to that role at Mitrais is impossible without at least a demonstrated working knowledge of this competency. This level of competency is defined within Mitrais’ Competency Review System as (in part):
• Contribute to the identification and prioritisation of potential risks throughout the project.
• Provide input to the development of risk management strategies and plans and to the development of reporting mechanisms for project risks.
• Contribute to the ongoing review of Project risks to determine the effectiveness of Risk Management plans.
• Changes to Project Risks are identified and recommended responses proposed to all stakeholders. Implement agreed changes to Project Plans as necessary.</p>
<p>We believe few software developers adopt such a structured and codified approach to this vital area.</p>
<p>All Mitrais project managers are, therefore, required to maintain a register of risks associated with particular projects and to report on the mitigation strategies in place to deal with them. The risks are assessed based on our experience over a large number of projects and post-mortem analysis of more and less successful projects undertaken by us in the past. These reports are provided weekly to Mitrais management and clients and the registers are updated regularly.</p>
<p>Our clients are welcome to raise risks to this register or offer input to mitigation strategies and we hope that the inclusion of risks on every report offers that opportunity.</p>
<p>Risks on the register can and do change as the project progresses. For example, the chance of an analyst missing a key requirement in a piece of software reduces once the requirements are agreed by the client, so the likelihood of that will be reduced (but never to zero – the client may miss it too!) as the project continues.</p>
<p>The risk register associated with most projects is very dynamic. An identified risk could be the lack of client resources available to conduct thorough user acceptance testing (which, in most cases, only a client can undertake). The absence of the right staff at the right time to conduct this essential step before a piece of software can go live can have a dramatic effect on the delivery schedule. In the run up to acceptance testing, we would expect to see this risk highlighted in the register. Once the acceptance test is complete, that risk would be closed and may not appear on subsequent reports.</p>