Risk Mitigation

You can do exactly four things with a risk

Every response to a risk is one of these. Naming which one you chose is what turns a worry into a plan.

Avoid it

Change the plan so the risk cannot happen. Drop the feature that depends on the API nobody trusts.

Reduce it

Make it less likely or less damaging. Build the risky integration first so you find out in week two rather than week ten.

Transfer it

Move the cost elsewhere - insurance, a contract clause, a supplier commitment.

Accept it

Decide to live with it, deliberately and in writing. This is a legitimate answer and completely different from not having noticed.

The register is the whole practice

A risk register is a short list: what could go wrong, how likely, how bad, who owns it, and which of the four things you are doing about it. It is boring and it works, because the failure mode in real projects is almost never that nobody could have predicted the problem. It is that three people each privately worried about it and nobody said it out loud.

The risks that actually sink software projects

Rarely the technical ones. In practice: a dependency on someone outside the team who has not agreed to the timeline; a requirement nobody has written down and two people understand differently; one person who is the only one who knows how something works; and a fixed date with fixed scope. Each of those has an obvious mitigation and each is usually left unnamed because naming it feels like criticism.

Do it early, when it is cheap

A risk found in discovery costs a conversation. The same risk found in week ten costs a re-plan, and in the last week it costs the deadline. Front-loading the riskiest work - the unfamiliar integration, the migration, the thing nobody has done before - is the single most effective thing you can do about risk, and it is free.