How to Manage Project Risks

The process in one paragraph

Managing project risk is four repeating steps: find the things that could go wrong before they do, work out which of them are worth worrying about, decide what you will do about the ones that matter, and check back on all of it regularly because the list is never finished. Teams that struggle with risk are usually missing one step entirely, often the last one, because a risk register written in week one and never reopened isn't a risk management process. It's an archived opinion.

None of this requires software, a certification, or a risk committee. It requires a list, a habit of updating it, and someone willing to say a date is in danger before it is obviously in danger.

Scoring: likelihood times impact

The standard method is a simple grid. Rate likelihood from, say, 1 (rare) to 5 (near certain), and impact the same way if it occurred, on schedule, cost, or quality, whichever is most affected. Multiply the two. A risk scoring 4×4 needs a plan this week. A risk scoring 1×2 goes on a watch list and gets revisited, not acted on.

The scoring itself does not need to be precise, and arguing over whether something is a 3 or a 4 wastes the exercise's point. What the grid is actually for is forcing a conversation: is this the kind of thing that would derail us, or the kind of thing we would grumble about and absorb? Most disagreements about a risk register are really disagreements about that question, dressed up as disagreements about numbers.

Impact deserves a second look before you score it. People instinctively rate impact on the work itself, and under-rate impact on trust: a risk that's small in hours but would be visible to a client or to leadership if it happened often scores higher in practice than the hours suggest.

The four responses, with real examples

Avoid means changing the plan so the risk cannot occur at all: swapping a vendor with a poor delivery record before the contract is signed, rather than hoping this time is different. It is the strongest response and the least often available, because it usually costs something up front.

Reduce means lowering likelihood or impact without eliminating the risk: adding a second reviewer to a step prone to error, or building a component in a spike before committing the full schedule to it. Most risk responses in practice are a reduction, not an avoidance.

Transfer means moving the consequence to someone better placed to bear it. Insurance is the classic case, but a fixed-price clause with a subcontractor for a risky piece of work does the same job on a smaller scale.

Accept means doing nothing further and living with the consequence if it lands, which is entirely reasonable for a risk that is unlikely, cheap if it happens, or too expensive to mitigate relative to its size. The mistake isn't accepting risks. It's accepting them silently, without writing down that the decision was made on purpose.

The risk register, as a working tool

A risk register that earns its keep has, at minimum: the risk itself in one sentence, likelihood, impact, the response chosen, who owns watching it, and the date it was last reviewed. Skip the owner column and the register decays within weeks, because a risk with no named owner is nobody's job to revisit.

Keep it short. A register with sixty rows, most of them scored low and untouched for months, trains people to stop reading it. A dozen rows that are all live and current does more good than a hundred that are mostly noise.

• Every risk has a named owner, not "the team."
• Every high-scoring risk has a written response, not just a score.
• The register has been opened and updated in the last two weeks.
• At least one item has moved (up, down, or off the list) since the last review.
• A risk that materialised is being tracked as an issue now, separately.

Where this tends to break down

The most common failure isn't skipping identification. Teams are usually good at naming risks in a workshop. It is the monitor step: the register gets built once, presented once, and then nobody owns keeping it current, so it silently stops reflecting reality within a month. If you only have time to do one thing well, make it the weekly re-look, not the initial workshop.

A smaller but common problem is confusing a risk with a task. "Get sign-off from legal" is a task, not a risk. The risk is "legal review takes longer than the two days we planned and pushes the release." Writing the task version instead of the risk version makes the register read like a to-do list, and hides the actual thing you are meant to be watching for.

How ShipSprint fits in

ShipSprint doesn't have a dedicated risk-scoring module, and this guide works whether you keep your register in a spreadsheet or a wiki page. What does help is where the register lives relative to the work: the built-in wiki keeps a page next to the project it describes, with history, and any sentence on it, including a risk line, can be turned directly into a task. A mitigation you decided on last Tuesday doesn't stay a sentence nobody actioned. That's a genuinely small thing, and it's the whole of the claim.