# On defining a risk appetite

Risk is an inherent part of any project, life even. We tend to talk about risk in terms of avoidance. In reality, a degree of risk is present in each decision you make. By being explicit about your 'risk appetite' you are able to make better choices and take control over it. This in turns lowers stress on your team, leading to a better project.

# Types of risk

It's good to be explicit about the type of risk you're trying to control:

• Budget (overspend, ineffective spend, shortage)
• Wasted effort (wrong solution or rendered obsolete)
• Data breach (GDPR-related, leaking system design info to competitors/hackers)
• Side-effects (leading to downtime, bugs, unintended behaviour)
• Hidden costs (e.g. tech-debt, afterwork)

Clients think to lean towards thinking about budget-related risks first, as that is their main "connecting line" to the project. Looking at the whole of the project and the ecosystem it moves in will make you more adept at representing their interests on a day-to-day operations level. And that's what good project management is all about.

Since attitude might change however, having a conversation on this from time to time is a good thing. In my experience, clients really appreciate you checking in with them to see if the risk attitude (still) matches their larger interests.

# Attitude towards risk

Here's a couple of attitudes you could adopt towards risk:

• Averse - limit risk to the maximum extent.
• Careful - limit risk as much is possible while trying to achieve 'X'.
• Rational - risk is acceptable when the potential 'payout' justifies it.
• Open - risk is embraced, failure is an option.

Project and company goals, as well as culture, will influence this. In general, speed and risk are on opposite ends. To take less risk in software you need to move slower. This means adding more testing and validation steps.

This needn't mean a waterfall project approach. Scrum could work fine, it just means you'll deliver less features (or none) per sprint. Kanban and feature-based releases might make more sense though, depending on the project specifics and risk profile.

# Putting a limit on risk

THE best thing you can do for any project is to put a limit on risk. Even if you have an open attitude to risk it's completely senseless to not define a boundary when you'll 'terminate and regroup'. A boundary might be as easy as a "non-extension" agreements on experimental approaches. This means that, by default, you refer to the 'proven' or 'safer' alternative if the experimental approach doesn't resolve the issue within X time. This is a great way to prevent the sunk cost fallacy!

Another easy improvement is to define "no go" areas on tasks. I love the idea of pitches on larger new functionality where the stuff you won't do and the rationale behind it is at least as interesting as the stuff you will do. It helps align expectations and 'guide' the work without going too much into implementation details.