01 / Simply explained
What is risk management in a project?
No project follows its plan perfectly. Requirements change, key people become unavailable, deliveries slip or essential approvals fail to arrive.
These events may never happen. But many can be identified early as potential risks.
Risk management is the systematic management of uncertainties that could affect a project's objectives. It involves identifying possible risks, assessing their likelihood and impact, agreeing appropriate responses and reviewing how they develop.
A risk is not yet a problem that has occurred.
- Risk: An event could occur and affect the project.
- Issue: The event has already occurred and needs to be addressed.
For example:
“A key supplier might not complete its delivery on time.” This is a risk.
“The supplier has missed the agreed delivery date.” This is an issue.
The distinction matters: we have to respond to an existing issue, whereas a risk still gives us an opportunity to act preventively.
Risk management can also cover opportunities. This article focuses on potential negative effects, which are a common focus in IT projects.
02 / Why it matters
When a small risk becomes a major problem
Imagine a project that appears to be going well.
The work is planned, the team is delivering the agreed outcomes and the next milestone looks achievable.
The project status is green.
Yet several team members have limited availability. An external supplier has not confirmed its delivery. And the next phase requires organisational approval.
Each of these uncertainties could affect the project.
Without active assessment and follow-up, it is easy to develop a false sense of security.
Only shortly before the deadline does it become clear that essential prerequisites are missing.
The team comes under pressure. Responses have to be organised at short notice, resources reassigned and decisions made under considerable time pressure.
Some of this could have been recognised weeks earlier.
Risk management cannot guarantee that problems will not arise. It gives a project team time and options.
That is where its value lies.
03 / Practical Example: IT Rollout
The rollout is scheduled. But are we ready?
Consider a fictional IT project.
A company plans to introduce a new application across several sites. The project team has prepared the technical solution, tested the application and drawn up a rollout plan covering all sites.
The first deployment dates are agreed.
However, several uncertainties remain.
Risk 1: Organisational approvals
The rollout requires approval from several stakeholders. If it is not received in time, deployment may be delayed.
Risk 2: Availability of local contacts
Each site needs people who can support deployment. Day-to-day operations may leave them with insufficient availability.
Risk 3: Technical prerequisites
Not all devices or user accounts have been fully checked. Problems might only become apparent during deployment.
Technical planning alone is therefore not enough to ensure a successful rollout.
The team needs to assess how likely these events are, what their consequences would be and what preventive action is possible.
It could agree firm approval deadlines, confirm local contacts early and check technical prerequisites against a checklist before each site deployment.
The key point: action starts before the risk occurs.
That is risk management in practice.
04 / How to put it into practice
Step 1: Identify risks early
Start with this question: what could prevent our project from achieving its objectives?
Look beyond the technical implementation.
Risks may arise from dependencies, resource shortages, organisational decisions, unclear requirements or external deliveries.
Discussions with the project team and relevant business teams are particularly useful. Different perspectives often reveal risks that the central project plan does not capture.
Describe each risk as precisely as possible.
Instead of “supplier problems”, write:
“If the devices are not delivered by the agreed date, the planned site rollout cannot be completed in full.”
A useful structure is:
If [possible event], then [effect on the project].
Step 2: Assess likelihood and impact
Not every risk needs the same level of attention.
A simple three-level scale is enough to get started:
| Level | Likelihood | Impact |
|---|---|---|
| 1 – Low | Unlikely | Minor disruption |
| 2 – Medium | Possible | Noticeable effects |
| 3 – High | Likely | Significant effects on project objectives |
Calculate the risk score as follows:
Risk score = likelihood × impact
Use these bands to prioritise risks:
- 1–2, green: Low priority
- 3–4, yellow: Medium priority
- 6–9, red: High priority
A risk matrix plots likelihood and impact on two axes. Each risk has a position and a corresponding colour.
This is especially useful in project status meetings: it quickly highlights risks that need particular attention.
Important: This scale is a simple decision aid, not an objective mathematical forecast. A rare event with potentially catastrophic consequences may require special action even if its calculated score is outside the red band.
| I ↓ / L → | 1 | 2 | 3 |
|---|---|---|---|
| 3 | 3 · Medium | 6 · High | 9 · High |
| 2 | 2 · Low | 4 · Medium | 6 · High |
| 1 | 1 · Low | 2 · Low | 3 · Medium |
Step 3: Define responses and residual risk
A risk register should go beyond description and assessment.
Significant risks need specific responses.
In the rollout example, these might include scheduling organisational approvals early, confirming local resources or carrying out additional checks of technical prerequisites.
Possible strategies include avoiding a risk, reducing its likelihood or impact, transferring certain consequences, or consciously accepting it.
Distinguish the original risk assessment from the residual risk.
Suppose the initial likelihood of a delayed approval is rated 2 and its impact 3. The original score is 6.
A firm approval schedule, early decision papers and regular coordination might justify reducing the likelihood to 1 after reassessment.
The residual risk would then have a score of 3.
However, this reassessment must not happen automatically simply because a response has been planned. It needs a clear justification, ideally after checking whether the action has been effective.
This makes it possible to see whether our responses are making a difference.
Step 4: Assign ownership
Every significant risk needs a risk owner.
This person makes sure the risk is monitored, its assessment is reviewed and agreed actions are followed up.
The risk owner does not have to carry out every action personally.
For example, the IT team might perform a technical check while the project manager owns the overall schedule risk.
Without clear ownership, even the best risk register remains just a table.
Step 5: Review risks regularly
Projects change, so risk assessments must change with them.
A risk rated low today could become critical two weeks later. Others may become less significant or cease to apply.
For many projects, a short risk review in the weekly project status meeting is sufficient.
Four questions help:
- Has the likelihood or impact changed?
- Have the agreed responses been implemented, and are they effective?
- Are there any new risks?
- Has a risk occurred and become an issue?
Only close a risk when there is a clear reason, for example because the event can no longer occur or the exposure no longer exists.
Step 6: Communicate critical risks in time
Not every risk needs to go to the steering committee.
However, if major objectives, budgets or milestones are at risk and the team cannot authorise the necessary action itself, escalate in time.
Provide clear information:
What could happen? How likely is it? What consequences do we expect? What response do we recommend? What decision do we need?
This is where risk management and decision management meet.
A transparent risk register highlights potential threats. Structured decision management helps turn the necessary responses into binding decisions.
05 / Tools & Personal Experience
A risk register does not have to be complicated
In many projects, a simple overview maintained regularly is enough.
| ID | Risk | L | I | Score | Owner | Response |
|---|---|---|---|---|---|---|
| R-001 | Rollout approval might be delayed | 2 | 3 | 6 | Project manager | Agree an approval schedule |
| R-002 | Local contacts might be unavailable | 2 | 2 | 4 | Site coordinator | Confirm resource availability |
| R-003 | Devices might not be ready for use | 1 | 3 | 3 | Technical workstream lead | Carry out readiness checks |
Fictional examples. L = likelihood; I = impact.
The full template adds status, the next review date and further information for follow-up.
A simple visual overview complements the table. A 3×3 risk matrix positions risks according to their assessment and uses colour to indicate priority.
This shows at a glance whether risks are concentrated in the low, medium or high bands.
In the Excel template, risks with the same current assessment share a bubble. The number in the bubble shows how many there are; the individual risk IDs remain visible in a separate mapping.
The chart does not replace professional judgement. Two risks with the same score may have different causes, consequences and appropriate responses.
A risk register is a means to support decisions and trigger specific action.
How I use risk management myself
While building my personal website, I considered risks that were not immediately obvious.
What happens if an external service becomes unavailable? How can I restore the website after a technical failure? And how do I protect the accounts used to operate it?
Rather than waiting for an incident to find answers, I started recording and assessing these risks systematically and putting appropriate responses in place.
These include a lean risk register, a backup and recovery strategy, and protection for important accounts.
Not every action is completed immediately. Some risks can only be reduced; others need continued monitoring.
For me, this illustrates the practical value: risk management means engaging consciously with uncertainty and being prepared. It does not require eliminating every risk.
That applies to a personal website as much as to a large IT rollout.
Takeaway
A good risk register cannot prevent every problem. It turns uncertainty into an opportunity to act.
Identifying, assessing and actively monitoring risks early gives you time for decisions and action, before a possible event becomes a real problem.
Template and further reading
Risk Register – Excel and Confluence
The accompanying Excel template lets you record risks, calculate scores automatically and visualise them in a coloured risk matrix.
A copyable Confluence template offers a simple alternative for teams that maintain project documentation centrally.
Related article: When Decisions Stall: Keeping Your Project Moving
Risk management and decision management often go hand in hand in everyday project work.