Risk Roadmapping for Game Development

A deeper dive into visualising risks

Hello, production people.

Today at GCAP, I ran a short demo of how to build a risk roadmap. Knowing that a large portion of the developers attending GCAP don’t have Producers on their team, the demo was adapted to be accessible for anyone in a leadership role to pick up and give it a go.

I’ll expand in this newsletter on how I’ve used this process myself. Firstly - what is a risk roadmap?

Risk Roadmap: Definition

A risk roadmap is a roadmap (high level project plan visualisation) you’re creating specifically to assess major unknowns and potential threats to your project success. The goal in creating a Risk Roadmap is to visualise all of the information you have about your plan (the work, how your team feels about the work, the knowns and unknowns, project constraints) to develop mitigation plans both within your team, and with your stakeholders.

The risk roadmap has two functions for two different audiences:

1. The process of building the roadmap
   Audience: The team
   Purpose: Stimulate discussion and deep thought about risks and mitigation strategies

2. The Roadmap visualisation itself
   Audience: Stakeholders/Project leadership
   Purpose: Illustrate where your clusters of risk are, to align on priorities and build support for mitigation plans

With that in mind, let’s talk process.

How To: Build a Risk Roadmap

The basics of building a risk roadmap are very simple, and much the same as the way you would draft any roadmap. The only real difference is that you should be constantly weighing what your major risk factors are - is it resourcing, immovable demo dates, alignment amongst tricky stakeholders? - try to establish what your top 1-2 risk factors are, and think about how you’ll visualise them on the roadmap.

Here’s the process and the thinking behind how I build a Risk Roadmap:

1. Build your backlog - define your epics as best you can. Piece of cake! (I’m joking but we don’t have time to discuss this right now - if you’ve got your broad brief of work broken into pieces you plan on implementing that’s good enough to go through this process in my opinion. Don’t want to have a “perfect backlog” to visualise your risks, or you’ll never do it.)

2. Run a backlog assessment with the team¹ - I like to use T-shirt sizing to get broad strokes sizing of each epic, you might want to use another estimation method. Most importantly here, you want to make notes of anything you’re sizing UP due to risks or unknowns. You’ll need this later.

3. Map out your epics on your timeline, considering your “push and pull” factors and project constraints - e.g. dependencies, resourcing, milestone dates. Don’t worry about getting it perfect first try, just get something in front of people as soon as you can - your developers will tell you what’s wrong with it, trust me!

4. Map out your other “risk factors” - In the below (simplified) example from the GCAP demo, I’ve identified resourcing as the major risk factor. So I’ve mapped out the project resourcing over time on top of the roadmap, to ensure it is always factored into any feature-based risk discussions. Team size (internally or outsourcing) has consistently been a layer I find useful on these roadmap. You might want to do this with external or stakeholder playtest cycles, special budget considerations - whatever is relevant for your project that may change over time.

5. With your basic roadmap visualised, run a risk assessment (with the relevant people on your team - on most projects I’ve worked on this would be with a group of discipline leads). There are many methods to produce this, I like to stick to a simple list of questions for each identified risk and just talk it through with the subject matter experts on the team.² Regardless of your preferred method, the end result you want is a stack ranked list of risk areas, categorised by type of risk³. Use that to colour code the risks on your roadmap. (I like to colour code by Type of Risk, and the change the opacity so that the highest severity risks are most obvious.)

6. Identify where there are patterns or clusters of risk. These clusters will tell you stories about your development, or rather, how your team feels about your development. Are a lot of our risks backend related? Is there a cluster of risk around our Alpha milestone? Are all the risks in Beta related to the length of the milestone? Circle them, and bring them to your decision making group. Focusing on the agreed highest priority risk clusters (you could calculate this by the combined risk score of all the items in the cluster if you want to be fancy about it) discuss the risk areas using How Might We statements (e.g. how might we become more confident in our backend system stability before Alpha?) and agree upon mitigation strategies.

7. Continue to hold your mitigation meetings at a regular cadence. Once a sprint is great if you can make time for it, or fold it in to existing leadership meetings. You don’t want to be doing this more frequently than fortnightly, though, because you begin to lose the perspective this exercise provides you. (Plus, you need to update the risk roadmap as you go and that can take a few minutes each time! As your project horizon draws nearer, your roadmap will become more refined, and hopefully your clusters start to break down and reduce in risk as your unknowns become knowns.)

Example (simplified) Risk Roadmap from GCAP demo:

And there you go! You’re using a Risk Roadmap.

What I like about this process is it’s flexible - you can do it with post it notes on a whiteboard, or in a specialised roadmapping tool. You can do it quickly in a few days to stimulate some fast discussion, or you can deep dive and create something really nuanced for a meatier strategic review. You can run it with your whole team, or a small group. It’s useful with a simple list of features, or a nicely refined backlog. A real one size fits all visualisation that has helped me support teams to solve complex problems together.

GCAP Materials

I hope you’ve found this helpful! For anyone who attended the GCAP talk, you may want to review the Miro board used in the demo. I’ve exported it as a PDF for you here.

If you use this process, or if you’re using a different method for visualising project risks I’d love to hear about it. You can get in touch with me via email.

---

Thanks again for reading, and if you’re enjoying this newsletter please do subscribe and share it with your favourite production person! As a farewell, here are some of my favourite recent watches and reads.

• Embracing Ambiguity - This GDC talk from Ruth Tomandl is wonderful, a great distillation of how to navigate a project with many unknowns.

• Collaborative Games for Agile Risk Assessment: There’s a lot of juice as always in this article on PMI about collaborative “games” for risk assessment. It’s nothing new - almost 10 years old now - but it reminded me of some important principles around collaboration, engagement and buy-in. I particularly enjoyed the Doomsday Clock, though that may just be the vibe of being in lockdown for another month.

• How I Sorted Out My Love Life using Affinity Mapping - This is just a funny read and a great explainer for the affinity mapping process for the uninitiated.

- Ally McLean

(Also, apologies for the delay in getting you all the Resource Management infographic - life! You know how it is. Watch this space.)

1. Note: Depending on the size of your project and the complexity of your backlog, you may want to do this in phases. On a recent project, I ran the whole team through setting up their “anchor” epics (putting a T-shirt size on work they’d already completed) and walked them through how to use documented assumptions to make broad estimates. Then, we broke the backlog assessment into smaller groups and completed the T-shirt sizing asynchronously in Slack threads using custom emojis for T-shirt sizes. This worked very well, and allowed a team of 30+ developers to all have a say in assessing a complex backlog in less than 4 days all up.

2. Here’s my list of risk assessment questions adapted from many examples and discussions over the years. Think about these questions as a way to understand if a problem is worth solving.

• Pillars: How is this feature linked to our project pillars? How would our pillars be impacted if this feature failed?

• Success & Failure: What specifically does it look like to the player if this feature fails? How do they feel the impact?

• Likelihood: How likely is this risk to come to fruition?

• Influence: How can we influence the outcome here? Is it out of our control or within our control?

• Experience: Does anyone on our team have experience navigating this risk before? How have they solved it? How have competitors solved this?

3. Type of risk can differ depending on your business model, the nature of your project etc. Most recently I’ve kept it super simple with 4 categories: Unknowns, Time Consuming, External Risk, Internal Risk. It should be pretty obvious to you what those categories should be when you look at the epics your team has sized UP for risk in your sizing exercise. You will probably find that over time as your project goes on, your types of risk change. You can re-assess your risk types at any time you feel necessary!