Risk Management for Software Development

Risk management is a system for identifying, addressing and eliminating issues that may be detrimental to the cost, schedule or technical success of a project or to the morale of the project team.

“Tomorrow’s problems are today’s risks.” Therefore, “risk” is clearly defined as a problem that could cause some damage or threaten the project schedule, but has not yet occurred.

If you don’t take the initiative to manage risks, you will face risks.

Software development is a high-risk activity, and there may be risks at any stage of the project development process. Adopting an active risk management method can make the project process more stable, obtain a high ability to track and control the project, and can avoid and transfer risks, or mitigate the adverse effects of risks.

Risk management is the process of identifying, analyzing, responding and monitoring project risks. It is a very important management activity in project management. Effective implementation of software risk management is the guarantee for the smooth completion of software project development.

The achievement of risk management must include three elements:

  • A risk management plan must be formulated in the project development plan;
  • The project budget must include the funds needed to solve the risk;
  • When assessing the risk, the impact of the risk must also be included Project planning.

Let’s discuss how we can take preventive actions to mitigate the risks that often occur during software development.

  1. Unclear requirements — Unclear requirements are frequently encountered problems in the software development process. Such problems are often manifested in many aspects such as undefined scope of requirements, unrefined requirements, unclear requirements description, missing requirements, and conflicting requirements. In the life cycle of the software development process, the waste caused by unclear requirements is the biggest and must be resolved as soon as possible. It is very difficult to determine user needs.

Preventive Actions

  • Let users participate in development through short and more frequent discussions and meetings
  • Develop and communicate with stakeholders using wireframe / user interface prototypes

2. For projects with a wide distribution of users and a large number of users, it is often difficult to comprehensively collect user requirements, and requirements research meetings are usually adopted to confirm requirements.

Preventive Actions

A few weeks before the meeting, we surveyed the needs of users in various regions and departments, and then gathered user representatives from all regions or departments to hold a requirement seminar to collect requirements through the meeting. This method is suitable for users who have certain IT experience.

2. 80 /20 Trap — When a project manager or a developer says that 80% of the task has been completed, you must be cautious. Because the remaining 20% ​​may take 80% of the time, or it may never be completed.

Software development projects often lack visibility in terms of project progress and software quality. The less visibility the project is, the harder it is to control the project, and the more likely it is to fail. We can enhance project visibility through iterative development, technical review, and continuous integration.

Preventive Actions:

  • Iterative development Using an iterative development model, the product delivery process is divided into multiple stages and delivered incrementally according to functions.
  • Technical review is an important part of ensuring software quality. Technical review includes code drill, meeting review and peer review. Code review can be a cross review between developers or a review of ordinary developers by senior developers; The meeting review is generally conducted at least once every two weeks, and the time of each review should not be too long, which is an important guarantee for the success of the project.
  • Continuous integration can disperse the final large-scale integration and commissioning process to the weekly and daily development progress of the project. So that everyone in the project can grasp the current overall progress at any time, and quickly find and solve the problems in the integration process.

3. Technological innovation is an exploratory and creative technological and economic activity. In the development process, introducing new technologies will inevitably encounter various risks. Measures such as T-shaped software development, and prototyping with new technology with spike user stories.

4. Performance issues —Due to the lack of software design insight, performance problems are often exposed after deploying the system or using a new system for a period of time. Performance problems usually require a lot of optimization work, or even partial or comprehensive redesign. Neither users nor developers want performance problems. The team needs to be aware of this problem, implement performance planning and testing throughout the development process, and include performance requirements in non functional requirements.

5. Usability issues — The usability of the software includes many factors such as whether the software is efficient, easy to learn, easy to remember, pleasant, and not easy to make mistakes. Often due to the poor usability of the software, users are dissatisfied and even eliminated by the market. In project development, attention should be paid to usability issues to avoid software usability risks.

Risk Breakdown Structure

We can use Risk breakdown structure to classify the potential risk for different aspects:

Risk breakdown Structure is the hierarchical decomposition of risks, starting from the root node element that represents the project, and going down to the various risk categories, and then finer level risks.

Besides presenting project risks in a Risk Breakdown Structure, it is possible to combine the use of Color Legend in representing the impact of risk. Take a look at the Risk Breakdown Structure example below, a legend of Impact with five items has been setup, representing the five levels of impacts that risks may have on the project with five distinct color code.

Here is a Risk Breakdown Structure example:

Risk Breakdown Structure Example

(Edit this risk breakdown structure online)

There are many Risk Management Tool you can use in structuring risks. Besides Risk Breakdown Structure, you may consider using the Cause and Effect Diagram as well (also known as Fishbone Diagram).

Conclusion

The earlier the risk is identified and managed, the more likely it is to avoid the risk, or to reduce the impact of the risk when it occurs. Especially in complex projects with a large number of project participants, a wide range of involvement, and high technical content should be strengthened.