What is Risk in Software Development?

Risk is often defined as the combination of the likelihood of a problem occurring and the impact of the problem if it were to occur.

  • Risk concerns future happenings.
  • Risk involves change in mind, opinion, actions, or places.
  • Risk involves choice and all the uncertainty that that choice itself entails.

Risk is something with which we are all somewhat familiar. We know that it is risky to jump out of planes, or invest money in the stock market. But we don’t always think of software development as risky – particularly if our software is not mission critical (that is, people’s lives don’t depend on it). While insurance companies and actuarial analysts spend most of their days dealing with risk, software development teams often spend a mere fraction of their project schedule thinking about risk.

In this series, we introduce you to some basic concepts and principles of risk management, and how these concepts and principles can be applied to software development projects to increase the probability of success.

In everyday life a risk is an exposure to the chance of injury or loss – a thing or course of action involving uncertainty and therefore danger. A risk, in the software industry, can be anything that may threaten the successful completion of a project: increased costs, delayed completion, loss of quality, or loss of market-share.

Two factors can be used to determine the magnitude of a risk: likelihood of occurrence, and impact of occurrence. When combined into a single indicator the risk can be judged relative to other risks as High, Moderate, or Low.

Many organizations still do not identify risks at the beginning of a project, or review and update those risks throughout the course of the product lifecycle. Estimating and planning is done as if all variables are known, and outcomes certain.

The reality is that risk results from changes in development personnel, market conditions, customer expectations, and even business conditions for the development organization.

Experience shows that the large majority of risks have a direct or indirect impact on schedule, and therefore implicitly on cost. Some have a direct impact on cost. The rest may have no direct impact on cost or schedule, but affect other areas of the project such as quality.

Some common risks include: the technical requirements of the product or system, constraints placed upon the project or product by the customer(s), budget, or schedule.

Types of Risks

It’s important to distinguish between direct and indirect risks. A direct risk is one over which some degree of control is possible whereas an indirect risk is one that cannot be controlled.

While one should not be unaware of the indirect risks, they are of little consequence in a practical sense: since one cannot change them, there is little to be gained by worrying about them.

Sometimes, an indirect risk may actually be a direct risk. For example, you may be dependent on an external supplier for a component or platform for your product. This appears to be a risk that cannot be controlled. But, by having contingency plans for those components, you can take control of the risk: develop a relationship with the supplier so they listen to your needs, choose alternate suppliers, or choose to develop the needed components yourself.

With indirect risks, you either have to gain some degree of control, or you need to just make note of them. Having them documented will allow you to easily revisit the risk and the decisions that were made as necessary.

To help determine if your project would benefit from Risk Management, look at your project and ask yourself the following questions.

  • Is the project scope firm or does the scope keep expanding?
  • Are estimates accurate?
  • Is there time to “do it right”?
  • Has the technology been proven?
  • Are the users of the system experienced with the type of system being developed?

These are just a few of the questions to ask yourself when looking for potential risks related to your project. If your answer was “No” or “Unknown” to any of them, it means that you are facing at least one risk to your project being a success.

About Trevor Atkins

Trevor Atkins has been involved in 100’s of software projects over the last 20+ years and has a demonstrated track record of achieving rapid ROI for his customers and their business. Experienced in all project roles, Trevor’s primary focus has been on planning and execution of projects and improvement of the same, so as to optimize quality versus constraints for the business. LinkedIn Profile
This entry was posted in  All, Planning for Quality, Risk & Testing, Test Planning & Strategy and tagged , . Bookmark the permalink.