Evaluating risk management methods for software projects

In order to complete a software project on time, one should do risk management and take the right measures to mitigate all likely risks. Several attempts have been made to identify typical project risks and recommended measures. One of the latest attempts was made by ICTU and NEN, in the standard NPR 5326. Saskia Woortman has done a thorough investigation in the relevance of the risks in this new standard by conducting a survey among practicioners.

Research goals and approach

The goal of the research done by Saskia Woortman was to validate the recommended risks and measures in the Dutch Practical Guideline NPR 5326 (“guideline for risk management during the development and maintenance of custom software”). This guideline contains only a limited number of risks and recommendations, and many commonly cited risks have been left out. For this research a long list was created based on literature research of 37 risks and 60 potential measures. These lists were then validated through two surveys among people with practical software project experience. The chart below shows the background of the survey participants. For the 37 risks, the question was whether these risks occur in practice. Each participant indicated how often the risk occurred in projects they have been involved in. For the risk mitigation measures, experts were asked whether they used this measure in their projects. Participants were also asked to suggest missing risks, and provide comments in case measures were not clear.

Most common software project risks

Based on the experience of the participants, the top and bottom risks were identified. The top risks that occur in practice are:

• dependency on a few key people
• Incorrect estimation of the work
• Misunderstandings due to suboptimal communication

The least occurring risks, according to correspondents are:

• Software releases occur too often
• Low morale of the team
• The team lacks the right expertise

An important missing risk in the literature is delays due to the time needed by decision makers to make decisions. This is an important cause of delays but is overlooked in the project management literature.

The bottom risks seem outdated, based on the adoption of more modern software development practices. An agile way of working would prevent such risks. The top risks are probably hard to avoid in innovative, ambitious projects.

Recommended control measures

Similarly to the analysis of risks, the risk mitigation measures have been separated in three groups. A top group consists of most recommended best practices. These are control measures that should be applied in most projects. Average practices are often applicable, and least effective practices are not widely applicable. This does not mean they should never be used. Some of these can be useful in very specific projects.
Examples of recommended best practices are:

• Identify important functional requirements
• Smaller, and if possible measurable, project milestones
• Realistic expectations of the project team for the final product

The following are least effective practices:

• Inspections at external companies
• Detailed multi source cost and schedule estimation
• Work within a central assurance framework

Results and conclusions

One of the goals of this research was to validate NPR 5326: Does this guideline contain relevant risks and countermeasures? The answer is mostly positive: The standard does not present a complete list of possible risks, but contains useful advice: ten out of seventeen of the control measures are part of the best practices of Woortman’s survey. For most projects, especially smaller ones, NPR 5326 is probably a good starting point for risk analysis. For larger and more complex project one should use the list of Woortman’s thesis as a basis for a more extensive risk analysis.

Woortman’s thesis can be downloaded here:Evaluating risk management methods for software projects

cover img src: Chuttersnap via unsplash