And how to avoid them

A risk matrix is a useful planning tool at any stage of development. It helps you anticipate problems, agree mitigations early, and reduce stress later.

I’m publishing this one as a Google Sheet so you can duplicate it, customise it, and use it in your own projects. It also comes pre-filled with a selection of common issues I’ve seen teams face, along with suggested steps to mitigate those risks.

If you’re new to risk matrices, don’t overthink it. The value is not the spreadsheet. The value is the conversation it forces.

You can find the Risk Matrix template here.

How to use it

Duplicate the sheet, rename it for your project, then work through it column by column. The value is not the spreadsheet, it’s the shared clarity.

The sheet has these headings:

• Area: the part of the project the risk relates to (for example team, tech, production, design, stakeholders, QA, live ops).
• Risk: a plain-English description of the problem you’re trying to anticipate.
• Severity (1–5): if it happens, how bad is it?
• Likelihood (1–5): how likely is it to happen?
• Impact: calculated automatically as Severity × Likelihood. This gives you a simple way to prioritise.
• Mitigating steps: what you will do now to reduce the chance of it happening, or reduce the damage if it does.

A simple workflow that works:

1. Start with the pre-filled risks, delete anything irrelevant, then add the ones that are specific to your project.
2. Score Severity and Likelihood quickly: don’t debate decimals. The point is ranking, not precision.
3. Sort by Impact and look at the top 10. Those are the conversations you’ve been avoiding.
4. Agree mitigating steps that are specific and testable. “Be careful” is not mitigation.
5. Review regularly (monthly is usually enough, more often around milestones). Update scores as you learn more.

Used well, this becomes an early-warning system. It also gives teams permission to raise uncomfortable topics before they become crises.

What goes in a risk matrix

If you’re wondering what “good” looks like, the template comes pre-filled with the kinds of issues that show up again and again in game and software teams: teams committing too early to a flawed idea, scope becoming unachievable, early engineering decisions creating long-term drag, documentation drifting out of sync, key people leaving, and all the small communication failures that quietly compound.

In other words, it’s not a theoretical model. It’s a prompt list for real problems.

Rather than trying to cover all of them in one post, I’ll do something more useful: take one risk that sits at the intersection of planning, finance, leadership, and culture, and unpack it properly.

Crunch culture is a symptom, not a plan

Crunch is the practice of expecting team members to work extremely long hours, often six days a week, to hit unrealistic deadlines. It can lead to stress, sickness, burnout, and eventually attrition.

Thankfully, expectations have improved in recent years. But crunch still appears, and when it does it usually has the same underlying causes.

Why unrealistic deadlines happen

Over-optimism

You almost have to be an optimist to attempt something as challenging as building a game. That optimism is useful, but it can also lead teams to over-promise. Leaders have to manage it, not amplify it.

Financial pressure

Studios often work on a small number of projects at once. If one falls away, scope creeps, or sales underperform, pressure builds fast. That pressure can push organisations into over-selling what they can deliver in order to win work and pay the bills.

Budgeting conventions that create tension

Game development often uses “resource-month” assumptions that don’t properly reflect real-world productivity loss to admin, training, coordination, and rework. When those rates stay static while costs rise, the gap turns into stress, and that stress turns into overtime.

None of this makes crunch inevitable, but it does explain why it keeps returning.

What helped me avoid it

During the years I ran studios, we rarely had to ask for overtime. The only person consistently doing very long days was me. I’m not claiming moral superiority here. I’m saying it was possible, and it was possible because we treated planning and discipline as part of the creative work.

A few mantras helped:

Under promise and over-deliver

It’s boring. It also works. Most crunch starts with a promise that should never have been made.

Focus on the goal, not the feature

If you’re clear on the outcome you’re trying to achieve, there is often a simpler way to get there.

Lay foundations carefully

It takes twice as much work to fix something once it’s become broken than it does to get it right in the first place. Early shortcuts are rarely free.

If you use the risk matrix as intended, as a living document that drives honest conversation, a lot of these problems become visible early enough to solve properly.

If you’d like help adapting the template to your project, or sanity-checking the risks you’re seeing, do get in touch.