A Comprehensive Guide to Risk Assessment

Software risk assessment is the process of identifying and measuring risks to your software project. There are two main categories of risk: that which is technological, which could be risks related to your code, tech stack, third-party tools, etc.; and project risk, which could be risks related to management, budgeting, timelines, or other operational choices that put the project at risk. Even though it seems obvious, it bears stating explicitly: Risk assessment before you get started lowers development time, costs, and effort for the overall project.

Let's take a look at a few different types of risk in these two broad categories.

Tech Risk

1. Development errors
   With any development project, there are inherent risks simply in the errors that may come up in writing code. Programmers are human. These errors may exist within the system for a long time without being known, perhaps until new updates or new features reveal them. These errors can pose a security risk for users or providers. They can leak data. They can simply slow the application.
2. Security risk
   Security is worthy of its own article. However here are just a few of the ways that a project can be made less secure. First is simply not prioritizing security from the outset. Additionally, risk can increase with the poor management of open-source tools. A common source of risk is open access to code repos or CI/CD pipelines.
3. 3rd Party risk
   Every third-party tool that is leveraged within the software brings with it its own risk. What's more, the level of risk can't be known because it is the risk born within that tool itself. In addition, a third-party tool can be implemented poorly within your software and introduce a level of risk based on that.
4. Technology stack risk
   Some technology stacks are riskier than others. This may be due to how new or outdated they are. Picking technology that is widely used and well-supported protects from various risks. If you pick an obscure programming language, it may be difficult to hire engineers who specialize in that. Very bleeding-edge languages tend not to be as well supported. No one should start with outdated technology. Even if you pick a popular, well-supported technology, there may be updates or other factors that affect your project outcome.

Project Risk

1. Schedule risk
   This type of risk happens when business deadlines, management, or other factors insist upon unrealistic deadlines for features. Asking your team to rush will inevitably result in errors or perhaps cut corners. This can happen when new features are required, or a huge pivot is introduced. In addition, user feedback, while useful when properly integrated into the workflow, can introduce schedule risk when not properly incorporated.
2. Budget risk
   This risk is often related to changing priorities, feature creep, and other requirements changes. It can also be at play when the project was estimated with optimism and rose-colored glasses. 
3. Team risk
   Ensuring you have the right experts in the right role in your team. Hiring people who are underqualified can bring their own risk to your project.
4. External requirements
   Whether it be bureaucratic requirements that come with government projects or business requirements from certain industries, these add complication and therefore additional opportunities for risk in a project.

It's important to also recognize that there are three levels of risk in terms of how apparent it is to the team. There are, of course, "known knowns". Another way you might think of this category is fully scoped features. You know exactly what it is, the requirements, the acceptance criteria, and its place in the greater context of the application. There are also "known unknowns". These are unscoped requirements. Or they could be risks that you have identified even if you don't exactly the parameters of that risk. Finally, there are "unknown unknowns". We must presume that there are risk factors that we haven't uncovered yet in any given project.

There are a variety of ways to mitigate the risk. Here are some of the best and lowest-cost ways to do so.

1. CI/CD
   Implementing a continuous integration and continuous deployment pipeline. Implement testing as early as possible and as frequently as possible to keep code clean. Integrating and deploying clean code continuously in order to keep the project up to date and avoid accruing technical debt.
2. Reduce the risk
   There are many ways to reduce risk. One is to rescope the project as a result of the risk incurred by certain architectural or technological choices. If the risk is located in your team, eliminate or resolve that team issue. 
3. Use incremental development methods
   Using a development method like agile allows teams to implement changes in an incremental method. It also allows for changing requirements, whether they come from the client or from user feedback to be less risky since the team can respond to them more immediately.