The value of risk management in a software project is that it turns surprises into decisions made in advance. An hour spent each month asking what could go wrong, and agreeing what to do about the few things that matter most, is cheap. Discovering in the final week that the old data will not load, or that the only developer who understands the system has resigned, is not. For most businesses it needs no special software: it is one page, a named owner for each line and a regular date in the diary.
What risk management is
A risk is something uncertain that would affect what you are trying to achieve if it happened. The international standard on the subject, ISO 31000, defines risk as the “effect of uncertainty on objectives”. A risk has not happened yet, and that is what separates it from an issue, which has. The whole value lies in that gap, because while a risk is still a risk you have choices.
Managing risk means doing four things repeatedly:
- Identify what could go wrong.
- Judge how likely each one is and how much damage it would do.
- Decide a response for the ones that matter.
- Check regularly whether anything has changed.
For each risk there are four possible responses. You can avoid it by changing the plan so that it cannot occur. You can reduce it, making it less likely or less damaging. You can transfer it, through a contract or insurance. Or you can accept it knowingly and set money or time aside in case it happens.
The risks software projects really face
Most software projects that go wrong do so for a small number of familiar reasons. In our experience these are the ones worth checking first.
The scope is not agreed. The two sides have different pictures of the finished system, and nobody finds out until delivery. The response is a written scope and acceptance checks before work starts, which is also what makes a fixed price dependable.
One person holds the knowledge. A single developer, internal or external, is the only one who can change the system. If that person leaves, the risk becomes the situation our page on what to do when your developer has left describes.
The data is worse than anyone thinks. Years of duplicates, missing values and free-text fields have to be moved into the new system. Data migration is routinely the most underestimated part of a project.
It depends on someone else’s system. An accounting package, a payment provider or a supplier’s interface behaves differently from its documentation, or changes during the project.
The people who must use it were not involved. The system is delivered and staff carry on with their spreadsheets. Choosing the right project stakeholders at the start is the response.
The platform is running out of support. Software that depends on a product its vendor no longer patches carries a security risk that grows every month. SQL Server 2016, for example, stopped receiving free security fixes on 14 July 2026, and Windows Server 2016 reaches the same point on 12 January 2027. Our end-of-support pages list the dates.
Nobody has tested a restore. Backups are taken but have never been used to rebuild the system, so nobody knows whether they work.
The supplier relationship ends badly. The business does not hold its own source code or the logins to its hosting, and cannot move.
A simple risk register, and how to keep it alive
A risk register is a table. It can live in a spreadsheet or in the tool the team already uses to track its work. Rate likelihood and impact as high, medium or low.
| Risk | Likelihood | Impact | Response | Owner |
|---|---|---|---|---|
| Customer data from the old system fails to load cleanly | High | High | Reduce: run a trial migration in month one and fix the data at source | Operations manager |
| Lead developer unavailable for a long period | Medium | High | Reduce: second developer reviews every change, and build steps are written down | Supplier’s lead |
| Accounts package interface changes | Low | Medium | Accept: one week of contingency held in the budget | Finance manager |
| Staff do not adopt the new system | Medium | High | Reduce: two users test each release, with training before launch | Department head |
Three things make a register useful and not a formality.
Every risk has one owner. The owner is a named person who watches for warning signs and carries out the response. A risk owned by “the project team” is owned by nobody.
The response is an action. “Monitor” is not a response. “Run a trial migration by the end of March” is.
The list is short. Ten risks that are reviewed are worth more than sixty that are filed.
A register written at the start and never opened again is the commonest way risk management fails. Three habits prevent that.
Review it on a fixed rhythm: monthly on a long project, or at the end of each development cycle if the team works in short iterations. Ask what has changed, what can be closed and what is new.
Make it safe to raise a risk. The developer who says “I am not sure this integration will work” in week two has done the project a favour. If bad news is punished, it is saved for the end.
Tackle the most uncertain part first. If nobody knows whether the old data can be migrated, try it before building the screens. Short delivery cycles help here because each one tests an assumption with real software, and a small paid discovery stage before a price is fixed does the same job for the unknowns in a quotation.
What it is worth
The benefits are practical.
- Problems are found while they are cheap. A misunderstanding corrected in a document costs an hour. The same one corrected after delivery costs a rebuild.
- The budget has a contingency with a reason behind it. A reserve tied to named risks is easier to defend, and to release, than a flat percentage.
- Decisions are made calmly. Agreeing in advance what happens if a key person leaves is easier than deciding on the day.
- The sponsor is not surprised. A director who has seen the risk on the register for three months reacts very differently from one who hears about it at the deadline.
- Supplier conversations become specific. Asking a supplier for their top five risks on your project, and what they are doing about each, tells you a good deal about how they work.
Risk management is not free of cost. It takes time and it requires people to say uncomfortable things aloud. It also cannot remove risk. Its job is to make sure the risks you carry are ones you chose.
If you work in a regulated sector, or the system handles personal or financial data, there may be specific requirements for assessing and recording risk. Check what applies to you and take advice.
Risk in systems you already run
Risk management is usually discussed for new projects, but a system that has been live for ten years has a register of its own. The questions are short:
- Could the system be rebuilt from its source code today, and who holds that code?
- Has a backup been restored successfully in the last year?
- Is everything it runs on still supported by its vendor?
- How many people can safely change it?
- If the supplier or developer stopped tomorrow, what would you have in your hands?
When we take over an existing system, the first step is to prove that it can be built from its source code, released in a controlled way and restored from a backup. A code audit gives you a written, plain-English report on the system’s condition.
A 30-minute exercise
Gather the sponsor, the person who decides priorities and the lead developer. Ask one question: imagine it is a year from now and this project has failed, so what went wrong? Give everyone five minutes to write answers separately, then compare. The items that appear on more than one list are your top risks. Give each an owner and an action, write them on one page and put the next review in the diary before anyone leaves the room.