How to Manage Risk in Software Development Projects

There are many benefits to complex risk management solutions such as Monte Carlo Risk Analysis or probability theory. On large projects technical risk management tools can be invaluable; however risk management in software projects requires a level of risk analysis more suitable for small projects and quick moving environments.

To deliver effective risk management in software development projects a simple risk management process that is easy to understand and focuses the project manager and teams attention to key risks is generally a much more pragmatic and useful tool.

A simple but disciplined approach will increase your project success and reduce your stress levels to boot. A simple risk management process involves Assessing, Reducing, Communicating, Controlling and Learning.

This risk management process is particularly relevant for software development projects, however can be applied to projects of any type or size.

Project managers need to assess the risk to the project in terms of time, cost and quality:

• What is the risk that the project will exceed the committed schedule?
• What is the risk that the project will exceed the budget he has signed up to?
• What is the risk that the project will not meet the quality requirements that have been set?

As part of the lessons learned process mature organisations should keep a record of things that have gone well or badly in previous projects. This is a useful source to help assess the risks to the project and should be used as a minimum.

Another approach to assessing risk is to hold a risk workshop where you invite all the key stakeholders and the project team to brainstorm ideas for what uncertainty could affect the project. Your lessons learned would provide a good starting point for this risk workshop.

The group should help you prioritise the risks in terms of impact and probability, the risks with the highest probability and impact should be concentrated on, leaving low likelihood and impact risks for another day. The key here is to allow those who have control over reducing the risk to concentrate on the biggest risks so that they can do something about it.

Uncertainty is generally not good for a project however it is inherent to the software development projects due to the general lack of requirements that can exist in agile rollouts.

Now that your risks have been identified you must do something to reduce that uncertainty and the probability and impact of those risks. These are actions and must be clear and have an owner who has the authority to do something about them.

For example there may be a risk that you won’t have enough resource in your software development team to deliver the project within schedule. An action could be to employ another 3 developers. For this to be carried through the action owner would need to have authority to hire people and sign off enough budget to pay for them.

As an experienced PM you may be able to identify solutions and actions to risks easily; however there is always benefit in holding another risk workshop to get additional views on the best ways to reduce the risks. For instance instead of hiring new resource someone may suggest reducing the scope of what you’re offering, which could reduce cost and time if acceptable to the customer.

Again, a key element of risk management is that general responses to risks should be captured as part of the lessons learned process to save time for future projects.

The project sponsor ultimately owns the output of the project so is responsible for its success; however it is unlikely that they have the technical knowledge held by the specialists in the team of a software development project. So somehow the Project manager will have to communicate the risks to them.

There are many ways to do this however the Sponsor should understand the risk management process that was used to gather the risk to give them credibility and how they have been assessed and the actions and strategies to minimise those risks. The sponsor can then make the ultimate decision as to whether the project should continue. There may be huge risks that have a high likelihood and impact, but the sponsor may decide to continue even if you suggest that is not wise. It is ultimately their decision as the will carry the can for it if it fails (although you can guarantee that some of the flack will roll down to the PM).

It is also wise to note that Project Sponsors very often expect delivery to the original budgets and schedules despite risk and simply expect the Project manager to manage the risk out of the project. It is for this reason that the Project Sponsor should be kept fully up to date on a regular basis.

The risks should also be communicated to other key stakeholders in the business on a regular basis to ensure they are aware of how the risks are affecting the project. They may also be able to play a key role in risk management by reducing the risks.

Simply identifying the risks and assigning actions to people is not enough to manage the risks. To deliver risk management a risks register should be created to capture all detail about the risk including:

• Risk ID
• Description of the risk
• The impact if risk happens
• Likelihood (1-5)
• Any actions to reduce the risk
• Risk owner – the person whose area the risk affects
• Risk Actionee – the person best placed to perform the action to reduce the risk (usually different but sometimes the same as the Risk Owner.
• Risk Status – open, closed etc.

Risk updates should be a key part of any project meeting and actions should be tracked to ensure they have been completed properly. The status of the risk should also be monitored to see whether its likelihood or impact has increased or reduced. The project team meeting is also a good place to ask the team if there have been any new risks identified, if so these should be captured onto the risk register. A risk register is a live document and should be updated regularly rather than just filed away.

When a project or stage has been completed a lessons learned review should be conducted to see whether the risks were reduced and managed effectively or whether there were issues with their risk management. These lessons should then be captured and communicated throughout the project organisation. These lessons can then be used on other projects to aid their risk management and minimise their risks.

The lessons learned role is often performed by the Project Assurance function and captured into process and standard risk lists as a result of the Centre of Excellence function. The Project Assurance role would then ensure that new projects are made aware of the standard risks that may apply to new projects.

Risk is inherent to all projects particularly in fast moving environments like software development projects. This does not mean that you should avoid taking risks, as high risk projects often deliver high rewards. You should however ensure that you have identified the risks correctly and managed and communicated them to ensure their likelihood and impact has been reduced effectively.