4. Risks and pitfalls

Every project carries risk. Some risks you see coming, others take you by surprise. The difference between a project that lands and a project that runs aground rarely comes down to bad luck, and almost always to whether someone has written down in advance what can go wrong.

What is a risk, and what is not

A risk is an event that has not yet occurred, but that will affect your project if it does. A supplier delivering late. A key person dropping out. A permit taking longer than expected. Technology that does not do what was promised.

That distinction between an event and a state may look like splitting hairs, but it determines whether you can do anything with it. "Insufficient capacity" is not a risk, it is a problem you already have; that calls for a solution, not a risk analysis. "Two team members leave before delivery" is a risk: an event that may occur, with a probability you can estimate and a consequence you can assess. If you notice that a line on your risk list is really a complaint, rewrite it as a sentence with "if ... then".

Step 1: getting risks out into the open

This is the hardest step, because you have to work out what has not happened yet. Four formats that help: have each team member name three risks and then cluster them; look at completed, comparable projects and the problems that came up there; go through the six phases of your own project asking what could go wrong in that phase; and talk to stakeholders outside the team, because they see things you miss internally.

At this stage you do not filter. A risk that turns out to be nonsense costs you one line on a list. A risk you never wrote down costs you your schedule.

Step 2: probability times impact

For each risk you estimate two things. The probability that it will occur, on a scale of 1 (very unlikely) to 5 (almost certain). And the impact if it occurs, also from 1 (negligible) to 5 (catastrophic). You multiply those two, and that number is your risk score.

Scores run from 1 to 25. Anything up to and including 6 can be left on the back burner: you know about it, nothing more. Between 8 and 12 a measure is called for, because this will affect you. From 15 upwards, a risk takes priority in your discussions with the client. A risk with probability 4 and impact 5 scores 20 and therefore tops the list. A risk with probability 2 and impact 2 scores 4 and can wait.

Those figures are not science. Two project managers rarely arrive at exactly the same score, and they do not have to. What matters is the ranking: you want to know which three risks are at the top, not whether something is a 15 or a 16. The conversation in which your team disagrees about that estimate often yields more than the outcome.

Step 3: doing something about it

Putting a risk on your list is one thing; doing something about it is the next. For every risk in the amber or red zone you choose a control measure. There are four ways of dealing with a risk.

Avoid. You change the approach so that the risk disappears. If a new technology is too uncertain, you choose a proven solution. You usually give something up in return, and that is the price.

Reduce. You bring down either the probability or the impact: extra testing, a second review, an interim delivery so you can see sooner whether something works. This is the category into which most measures fall.

Transferring. You place the risk with another party: an insurer, a fixed-price agreement with a supplier, a service contract with a penalty clause. The risk does not disappear, it becomes someone else's.

Accept. You are aware of it and deliberately do nothing about it, because a measure would cost more than the damage it prevents. You do keep an eye on it. Accepting is a choice, not an oversight.

For each measure, record who will carry it out and when, otherwise it remains no more than good intentions. And agree on a trigger alongside it: the signal by which you recognise that the risk is actually materialising. For example: if the technical drawing has not arrived by 15 March, we switch to supplier B. Without a trigger, you only notice that the risk has occurred once it already has consequences.

The five pitfalls

Alongside the risks specific to your project, there are patterns that recur in virtually every project. They have less to do with bad luck and more to do with behaviour.

Scope creep. During delivery the client keeps adding requests. Each request is small in itself, but together they cause the project to overrun and the budget to become too tight. The antidote is in chapter 2: an explicit out-of-scope list, and every change submitted through a formal request setting out the consequences for time and money.

Overly optimistic planning. Estimates are made under ideal conditions, without any buffer for holidays, illness or unexpected additional work. As standard, add fifteen to twenty-five per cent to your estimate, or work with a separate risk buffer that you manage deliberately.

An unclear brief. You start without it being clear what the result should be. Halfway through it turns out that the client and the team had different pictures in mind. Skipping the definition phase looks like a time saving and costs many times more later on.

Neglecting communication. Everyone is busy, so the steering group gets no update, the team does not know what the client thinks, and the end user only hears at delivery that the project exists. Unexpected resistance is then all but guaranteed.

No intervention. You can see things going wrong, but you hold off on intervening because you hope it will sort itself out. It rarely does. The sooner you name a problem, the more options you still have.

Summary

• A risk is an event that has not yet happened, not a condition that already exists. Write it down as "if ... then ...".
• Collect broadly first and don't filter; then estimate the probability (1 to 5) and the impact (1 to 5) for each risk.
• Probability times impact gives the risk score: up to 6 keep an eye on it, 8 to 12 take a measure, from 15 give it priority.
• The ranking matters more than the exact figure. The conversation about the estimate usually yields the most.
• Four strategies: avoid, reduce, transfer or accept. Accepting is a choice, not an oversight.
• For each measure, record an owner, a date and a trigger, and discuss the list every two to four weeks.
• The five pitfalls: scope creep, over-optimistic planning, an unclear brief, neglecting communication and adjusting course too late.
• Watch for trends, not just for the colour at this moment. Four weeks of amber is worse than one week of red.