How to manage risk in software development.
Custom software can be transformative for your business, but it’s easy to go wrong. Here’s how to manage the risks involved for the best chance at success.
What is software development risk management?
The fundamentals.
Before we get too deep into the detail, we first need to understand what risk management is.
What is software development risk?
When people talk about software development risk, they’re typically referring to unplanned or unexpected events that harm a software project’s progress or eventual success.
These risks are always present, but are made more likely to occur due to a lack of knowledge, experience, or foresight on the part of a development team. They are also affected by external events and business pressures.
Risks most commonly cause harm in the form of development delays, cost overruns, and quality issues, but they may also cause more serious problems like a loss of revenue, legal issues, or lasting reputational damage.
What is software development risk management?
Risk management helps your software project to stay on track, within budget, and to maintain quality standards. It involves four basic activities:
- Awareness of risk factors that affect software projects.
- Understanding which risks are most likely to affect you.
- Planning ahead to reduce the chance they occur.
- Knowing how to mitigate their impact if they do.
We’ve categorised common risk factors below, and included mitigation steps for each. Read on to save you and your team time, money and heartache.
What are the biggest risks in software development?
Risk categories.
Rather than trying to think of every possible risk factor, it’s helpful to break them down into risk categories.
Requirements changing too often
When requirements change frequently, we usually increase project complexity. This incurs delays and additional costs.
Project complexity increases because new requirements are typically added more than old requirements are removed. This is informally known as “scope creep”.
Another factor is that new requirements often mean reworking existing code, which is more time consuming than working from a blank slate, as would be the case if the requirements were known up front.
There’s also a challenge in communicating updated requirements effectively. It can be hard to keep everyone aligned, and so communication overheads increase, contributing to delays and costs.
Despite these risks, changing requirements are completely normal, especially when the software project is complex, innovative, or the best solution is unclear. You just need to effectively mitigate the risks.
Mitigation steps
Planning: Make the effort to unearth non-obvious requirements before development starts. It can be tedious work, but it means far fewer surprising additions later.- Agile development: Consider an agile development methodology for your project. Agile methodologies are very accommodating of frequent and continual changes.
- Communication: When requirements change, ensure stakeholders understand the impact on costs and timelines. Communicate these more explicitly at higher levels.
Technical Complexity and Innovation Risks
When development projects involve new or complex technologies, there’s a higher risk of unexpected delays.
When developers aren’t familiar the technology they’re working with, they use a mixture of documentation, trial & error, and educated guesses to learn.
This unfamiliarity slows the development process, and makes it prone to wrong assumptions and misinterpretations. It also makes accurate time estimates much harder for developers to give.
It’s normal for developers to do some learning on the job, but if they’re too unfamiliar with the technology they’re working with, it can mean significant delays, cost overruns, and quality issues for your project.
Mitigation
- Identification: Work with your development team to identify areas of technical unfamiliarity, and make sure this is factored into estimates and timelines.
- Learning: Where there are gaps in your team’s expertise, invest in training and learning resources for some key team members to bring them up to speed.
- Proof of concepts: Before it blocks progress, prove the unfamiliar technology with a proof of concept or prototype. This aids familiarity and helps to identify pitfalls early on.
Resource and Staffing Risks
A poor mix of skills on the development team means you risk not delivering the project on time or to the required quality.
It might be that the team is too junior and so is unable to deliver what’s required on time, or too senior, and so becomes too expensive to deliver an acceptable return on investment for the business.
You may also face knowledge silos, where a key knowledge or skills are held by too few individuals. In this scenario, you risk these people bottle-necking your progress, or stopping it completely if they leave.
Mitigation
- Hiring: Identify the skill sets required for your project and make sure that you have the right people in place. Do this for both employees as well as external agencies and contractors.
- Training: Consider training existing employees to fill your skill gaps as a cheaper alternative to hiring that also builds significant good will within your team.
- Knowledge share: Where silos exist, break them down by having key team members knowledge share with each other to avoid bottlenecks and blockers.
Budget and Schedule Overrun Risks
Projects running over time and budget are a risk in themselves as they cause a loss of trust and delay a return on investment.
Late projects are particularly damaging if their completion is linked to a specific event, such as a product launch or a regulatory deadline. In these cases, a missed deadline might mean the project is scaled back or canceled altogether.
Budget and schedule overruns can also put subsequent investment in a project at risk, as business departments will turn elsewhere to get the revenue they need. This can mean the “full vision” of a project is never realised, lessening or even eliminating the return on investment.
Mitigation
- Tooling: Use project management tools and Agile development methodologies on your project. These will make it much more obvious if you’re beginning to overrun.
- Priorities: Try to complete the most business critical aspects of the project first. This will ensure any if things do overrun, you can still deliver a stripped back version of your vision.
- Preparedness: Have a plan for how to descope the project while preserving value. This way, if things do begin to overrun, you can respond quickly and effectively.
Compliance Risks
When quality or industry standards are not met, you risk legal issues, reputational damage, and loss of revenue.
This most often occurs when bugs and performance problems are left unaddressed in your product, resulting in a poor user experience which hinders the value you’re able to deliver.
However, non-compliance with industry standards might also mean your software stops working when external services it relies upon force adherence to a new standard your software doesn’t support.
Different jurisdictions also legally require compliance with certain standards. Flouting their requirements can result in large fines or even legal action.
- Tracking: Make sure that you’re tracking bugs and performance issues, and that you’re proactively addressing them quickly enough to preserve product quality.
- Compliance awareness: Make yourself aware of any standards or legislation affecting your project, and get compliant with plenty of time to spare before launch.
- Audits: If you’re unsure, you can pay for a technical audit from a specialist firm for things like legislation compliance, security, or performance problems.
Vendor and Outsourcing Risks
External software vendors and outsourcing development activities can be extremely powerful, but it can also introduce risks around overheads and lack of transparency, and outages.
The most common outsourcing going wrong of this occurs when a key part of a development project is outsourced to a third party, and they fail to deliver. This may be because they’ve not been transparent on progress, or could be because of a misunderstanding on requirements.
Software vendors can also introduce risks around outages and downtime. These outages typically come from services your software relies upon to function such as hosting platforms, email providers, and payment providers. If your software is dependent on a service that stops working, your software will also stop working.
- Contracts: When outsourcing development, make sure that you have a clear contract that specifies expected uptime, performance characteristics, and security standards. It should include agreed timelines for bugfixes, and penalties for non-compliance.
- Communication channels: Ensure that you have an effective way to communicate with vendors and other third parties with who your software project is dependent on. This keeps communication overheads low, allowing you to address issues quickly.
- Protect your core: Pay extra attention to core business functionality. Ensure downtime of non-essential services doesn’t break your software, and implement fallbacks where possible.
User Engagement and Satisfaction Risks
It’s surprisingly common to build software that’s technically brilliant, but that doesn’t meet user’s wants or needs.
The most common example of this is new projects started without adequate market research to validate the problem and solution, and so the final product either solves problems ineffectively, or attempts to solve problems that don’t exist.
However, it’s also important to remember that users expectations and needs change over time, and so there's another risk in not evolving a successful product after launch. A failure to keep up with your market can lead to a product that was once effective becoming obsolete.
Mitigation
- Validation first: Talk to users to ensure your problem exists, and that your solution the correct one before you invest money in developing software.
- User testing: Before and after launch, conduct regular user testing to keep feedback loops short and ensure that you’re solving the right problems the right way.
- Product metrics: Define and measure product performance metrics. Use these to inform your product roadmap, and to identify potential issues early.
Security and Privacy Risks
When you build insecure software, you risk loss of customer trust, huge legal bills, and major reputational damage.
A serious example of this would be when a security breach occurs, and customer data is leaked to the Internet. In many jurisdictions this can incur huge fines, and open your organisation up to legal action from those affected.
A much more common example is using basic insecure practices in your software. These get noticed by tech-savvy users, who alert others, which then affects trust in your organisation’s ability to safeguard their personal data.
Mitigation
- Secure procedures: Work with your development team to put procedures in place that mean customer data is stored securely and handled sensitively.
- Staff training: If necessary, get your team trained in secure development practices. This is particularly important if you’re working with lots of sensitive data.
- Planning: Make a plan for what to do if a security breach occurs, with particular attention to how you’ll alert your users and the relevant authorities.
Market Risks
A disruptive new technology or competitor giving away your service for free can quickly render your product obsolete.
While not so much a risk in the day-to-day, a lack of awareness of market trends can lead you to build something without a future trajectory, preventing a future return on investment.
Your project’s viability can be affected particularly harshly when the market changes as a result of a technological innovation that eliminates the need for your product or service.
We’ve seen this recently with the rise of Artificial Intelligence (AI) powered services removing a lot of human input in creative industries. For example, all of the illustrations in this post are AI generated for next to nothing, when a couple of years ago they would have had to be hand-drawn at significant cost.
Mitigation
- Stay current: Keep an eye on the market, and be aware of any new technologies or competitors that could affect your project’s viability and value.
- Adapt quickly: When new technologies or services come along, update your product quickly to remain competitive. This may mean new features, or a product pivot.
- Stay flexible: Develop your product in small, fast iterations to minimise the time it takes to realise value, learn from your users quickly, and avoid large sunk costs.
Project Management Risks
These occur when project managers lack the experience or technical knowledge needed to manage the project effectively.
If a project manager is too inexperienced, the detail and continual context switching required in a complex software project might be too much for them to handle. This will lead to mistakes, delays and cost overruns.
It’s also helpful for software project managers to have some technical knowledge, especially if they have limited project management experience. Technical knowledge helps them to make better decisions to deliver within the constraints of the project.
Mitigation
- Relevant experience: Ensure that you have a project manager with the experience required for your project, and that they have the necessary technical knowledge to manage the project effectively.
- Consult the team: Encourage your project managers to consult developers on the impacts certain decisions could have on the project.
- Encourage honesty: Where project managers have technical gaps in their knowledge, encourage them to be open with their team and stakeholders rather than making decisions based on incorrect assumptions.
Which software development risks apply to me?
Size matters.
Use the following to figure out which risk categories apply most to your business.
Are you a smaller company?
In smaller companies, risks like resource limitations, technical expertise, and budget constraints are more pronounced. There’s often also less experience (sometimes no experience) in managing software projects. The stakes for a software project are also typically higher, with the company being more dependent on its success.
On the other hand, small companies find it easier to remain agile and move quickly. Communication overheads and development costs are also often much lower than they would be in a larger organisation. They also generally have a much larger upside advantage if their project is successful, as the costs of scaling software for a small company are much lower relative to the return that software can deliver.
Are you a larger company?
Larger companies might face risks with complex project management, internal bureaucracy, and stakeholder alignment - so much so that it’s common for the bulk of development cost to come from communications overheads alone. Large companies may also have a lot of legacy systems and processes that need to be integrated with, which can be a significant challenge.
On the other hand, larger companies often have more experience in managing software projects, and have more resources available in-house to run them. It’s also generally much less risky for a large organisation to take on a new software project, as they typically have multiple revenue streams and more significant reserves to see through a project that doesn’t go to plan.