Transforming Outcomes with Software Engineering Risk Management Strategies

Most project managers have trouble seeing around corners. They usually fail to see that the project plan is heading towards a potential problem, until it’s too late. By then, the development team has already spent so much time on a given software project that it’s past the point of no return. It’s too late to change the plan, and it’s too late to scrap the project.

You end up with budget overruns, blown deadlines, and/or unusable software.

Software risk management is about seeing around corners. It’s the art and science of identifying, evaluating, handling, and controlling risk. (Ideally, before things blow up!)

Surprisingly, a PMI survey found that only about 60% of organizations use risk management practices consistently or occasionally.

In this guide, we’ll explain how software engineering teams can better conceptualize risk; and how they can build a risk management plan to help with both, risk handling (seeing around corners) and risk mitigation — removing the corners altogether. 

What Is Risk Management in Software Engineering?

Risk management in software engineering is both the process and the strategy for removing or minimizing risk involved in software projects. 

It entails assessing, identifying, and prioritizing project risks or uncertainties. With it comes planning, monitoring, managing, and mitigating risks. Even meticulously planned projects come with their fair share of risk factors. 

That’s why project managers need to account for these potential risks in their planning process, by including project scope and cost estimates to stay on track. Also, they need mitigation strategies to handle risks that arise throughout the project lifecycle. 

Principles of Risk Management in Software Engineering

Risk management can be broken down into five key principles:

1. Risk Identification
2. Risk Assessment
3. Risk Handling
4. Risk Mitigation and Control
5. Risk Monitoring and Review

Risk Identification

The first step to handling or mitigating risks is to identify the risks at play. 

This is an active process that should be taken care of by a dedicated project manager or other member of the team. Their job is to unpack the project’s details and identify any and all potential risks that could be a set back. 

For example, this workflow from the US Department of Energy outlines the step-by-step methodology that their teams use to identify risks at the beginning of a project.

Ideally, this is an integrated part of the overall software development process. 

Every new project is subject to a risk analysis that then feeds into the software budget, planning, and timelines.

In general, it’s important to identify three main types of risk that crop up frequently in software projects:

1. Technical risk – which involves the choice of technology, integration of tools and software, hardware setup, security, data protection, dependencies, and any other technical factor that could potentially derail the project or significantly change its scope or costs. 
2. Project risk – that includes the software project’s timeline, budget, resources, scope, and software requirements. This could stem from technical risks or other factors like internal resource constraints, stakeholder changes, or scheduling conflicts. 
3. Business risk – which includes any risk associated with the business outcome of the project; be it the costs of development, business requirements, marketability, or cost to operate.

Using a checklist or systematic analysis, there should be a workflow for identifying as many risks as possible, upfront in the project. At this stage, they only need to be potential risks, and they can be of any size or severity. 

Risk Assessment

Once the risks have been identified and broadly categorized, you’ll need a framework to assess them further, and prioritize the actions and resources needed to address them.

Internal vs External Risks

First, you’ll want to further categorize each risk according to whether it’s an internal or external risk factor.

Internal Risks

Internal risks are within reach of the organization. They can either be handled directly as part of the project planning; or you may need to take mitigation, control, or monitoring steps to reduce the risk, if unable to eliminate it entirely. 

Examples include:

• Technical issues: incompatible technology, systems, or frameworks
• Resource management: organizational turnover, or lack of budget and technical equipment
• Project management: shifting project schedule, metrics, or budgets
• Requirements management: lack of approvals, ambiguous software testing requirements, or overly broad specifications

External risks

External risks originate outside, and are beyond the organization’s (or project team’s) control. In most cases, external risks can only be managed (or minimized) through mitigation, control, or monitoring strategies. In some cases, the risk is simply unavoidable.

External risks include:

• Market risks: unruly market trends or competitive environments
• Legal and regulatory risks: changing laws or regulations
• Vendor risks: failure to deliver or meet requirements, bankruptcy, or personnel issues

At this stage, you should combine both categories in order to group your software development risks by type and origin.

This is important because it will help you determine whether you should consider risk handling to address your risks, or risk mitigation in an attempt to shield the project from the impacts of your risks.

Risk Impact

Next, you’ll want to score each risk according to its potential impact on the project.

You can do this by assessing each risk according to two factors: 

1. Severity – the size or magnitude of the impact this risk could have on the overall project.
2. Probability of occurrence – how likely this risk is to occur and/or have the expected outcome.

You can combine these two factors into a simple matrix that informs you of the impact of a risk.

Risk Prioritization & Planning

Finally, you can use the risk impact assessment to prioritize those risks that require action. Ultimately, each one of these risks should have a prioritization and an action plan.

Prioritize solutions for the highest impact risks — which are most likely to happen, and have the greatest effect on the success of your project. 

Then work backwards. The lowest-impact risks may be acceptable risks that require no further action.

For each risk, you’ll then need to determine the best course of action. In broad strokes, most risks will require one of three types of action plan:

1. Risk handling: direct actions taken to eliminate the risk or greatly reduce its likelihood or impact
2. Risk mitigation and control: systemic actions to reduce or eliminate the risk
3. Risk monitoring and review: ongoing actions to assess or measure the risk

That’s where you should go next. 

Risk Handling

First up: handle the risk outright.

Whenever possible, project plans should include actionable steps to address any potential risks that are internal and addressable through targeted intervention. 

In other words: fix the stuff you can, before it becomes a problem.

For example, one of the technical risks you identify could be that your team is planning to implement a new technology they’ve never deployed for this type of project. That would represent a significant risk.

A simple risk-handling measure would be to choose a proven technology instead; or conduct a deeper analysis to confirm the viability of this new tech before committing to its use. 

Team members can get creative with risk handling. Sometimes it’s helpful to conduct an old-fashioned brainstorming session where developers and stakeholders ideate on ways to eliminate or resolve potential roadblocks. 

But this is just one piece of the software risk management process.

Risk Mitigation and Control

Not every risk can be stopped or handled. 

Many risks are either external (you have minimal control over them) or simply unresolveable.

In addition to handling the risks that have been identified through proactive measures, the next step of an effective risk management strategy is mitigation and control; i.e. taking steps in order to minimize, either the impact or the probability of the risk. (Or both!)

Usually, this involves implementing new policies, procedures, or processes that address the risk at a systemic level. 

Key example: project risks such as budget overages or missed deadlines are simply unstoppable. It’s not a switch; you can’t just stop things from taking longer than they’re meant to.

But these risks can be mitigated. 

One risk mitigation strategy is to employ time tracking across the organization.

Using historical project and time data as part of the software project management process enables smarter, data-driven decision making. Software development projects are more likely to stay on track, and on budget, if the planning process is rooted in empirical data collected from past projects, rather than generalized estimates and forecasts.  

This improves the accuracy of the project scope, budgets, and timelines.

Again, this doesn’t eliminate the risk; but it introduces mechanisms that reduce the risk’s impact:

• Lesser probability of occurrence: estimated work hours, budgets, and timelines are more likely to be accurate and less likely to become a significant risk factor.
• Lesser severity: in cases where estimates are inaccurate, they’re more likely to be within an acceptable margin of error if based on real-world data.

The key here is to uncover strategies that allow you to contain, minimize, and manage risks using levers that are within your control.

Other mitigation strategies would include things like transferring the risk. This could mean outsourcing to a third-party contractor, using an insurance policy to cover potential loss, partnering with another company, or using a penalty clause in a vendor agreement.

Risk Monitoring and Review

Some risks are entirely unmanageable and cannot be mitigated. The best you can do is to monitor the situation. 

Once you’ve implemented risk handling and risk mitigation strategies for all of the risks that can be addressed through one of these two processes, the remaining risks should be thoroughly documented, and monitoring plans should be set in place.

For example, if you’re unable to draw from historical developer time data as part of your mitigation strategy, you can instead choose to deploy time tracking for the duration of the project. That way, you end up dealing with a monitoring strategy. 

You’ll be able to measure and track the timeline of the project better, and intervene if the data suggests that the project is at risk.

Stack the Deck for Success

Ultimately, every software engineering project involves risk. After all, if it was easy, anyone could do it. 

The key to remember with this project risk management business is that it’s all about understanding the fundamental nature of the risk, then taking the appropriate (and possible) steps to tip the scales in your favor. 

Your job is to stack the deck for your team. 

Give them the highest possibility for success, then communicate clearly the risks involved and actions taken to handle, mitigate, control, and monitor those risks. Always keep your project stakeholders informed of the risks and any mitigation plans you create.

As you’ve probably heard it in The Hunger Games: may the odds be ever in your favor.