Read Time: 6 Minutes

One of the top 5 questions we get is, “How do I deal with uncertainty on my game project?” The reality is that most people don’t handle it at all.  We layer over uncertainty with buttoned-up roadmaps, robust ticket tracking, and spreadsheets galore.  If we lock everything down in enough detail up front, the uncertainty won’t be a problem.  This (traditional) approach fails for a couple of reasons.

• Deciding on an answer right now might make your project plan more certain, but it doesn't necessarily make a good game more certain.

• There are a million reasons why the game, team, market environment, technology, etc could change tomorrow.

• We make a bunch of assumptions we’re not testing. If we’re not testing we won’t learn. If we don’t learn, we make bad decisions. Making bad decisions results in a bad game.

I’m excited that so many people are asking this question because it’s probably one of the most important things we need to consider as leaders. There is no perfect answer for how to burn down uncertainty, but if you focus on the key things we outline below, you’ll be better off on your projects.

Create Loops

The first and most important thing you must do to build a system that naturally addresses uncertainty is to create loops everywhere. If you create loops in all critical areas of your project and teams, you accept the reality of change and build the tools to react gracefully.

OK, but what does that even mean? As managers, we are trained to think of things linearly. We’re trained to build things linearly. Everything is an assembly line. If we can just come up with the proper steps, we can document things and then make a plan, right? Wrong.

What you should do is write down all of your assumptions, write down all of the outstanding questions you have (more on that in a second), get to work, then take a step back at the end of the day and ask, “What did we learn?”. Then, you decide what you will do differently tomorrow for better results. That’s a loop. You should have loops for:

• Your roadmaps (review them regularly and update them. They are not static documents)

• Your team process (should be changing all the time based on what you learn)

• The game itself (you should be testing your game as often as possible and reprioritizing based on how those playtests go)

• Your stakeholder/update meetings (talk about what the team has learned and what changes you recommend - it will build trust with your leaders!)

Keep this phrase always in your mind: Inspect and adapt. Look at what’s happening.  Look at what you’ve learned. Make changes. Try again.

This might sound simple, but consider what you’re focused on on your current project.  Are you executing on a 4-month milestone, too heads down to consider what’s come up in the last two weeks? Are you following a design doc to the letter even when occasionally you think….” this feature doesn’t make any sense?” These are just some examples of linear execution, which often fails in games.

Action:

To start addressing uncertainty today, the simplest thing you can do is find time for your team to sit down and discuss everything they’ve learned from working in the last two weeks.  Inevitably, recommended changes will come up. You should help your teams take those changes on and get them done.  The more you do this, the more you’re thinking in loops and less in lines!

Prioritize Answering Questions

People think backlogs and project tracking are just for work. They are also for questions. I guarantee your team already has some big questions about the project.  “Should we use our own engine or an off-the-shelf one?” “How important is fishing & mining vs improving the UI right now?” “How critical are the tools for the artists in preproduction?” “Will we need audio for this? How much?”

If all your team is doing is working nonstop, you won’t ever have time to answer these questions. If all you’re tracking is work, you will forget these questions were even asked.

Moving through the “cone of uncertainty” is just as much about asking and answering questions as it is about doing work.  If you’re not in production, answering questions is more essential than doing work. You should look at answering questions “as work.”

On the largest projects I’ve ever worked on, I kept an eye on what the biggest questions were.  I got my other leads aligned on what questions were most important to answer and which answers were most critical to the project's success. Then, I made sure we were working together to find answers. It also helped me a hell of a lot in stakeholder meetings. When I put the five biggest questions up on the screen for my stakeholders to see, not only did they have a chance to throw in their opinions, but they were not surprised when uncertainty inevitably “threw a wrench” into the plan.

I’ve learned time and time again that so often, “the work” is the easy part.  Asking the right questions and getting answers efficiently makes or breaks projects.

Action:

Create a list of the biggest/most important questions for your team or project. Get input from other leads and your teammates. Prioritize that list and make sure that the questions that are most impactful to the success of the project people are working on answering. Get visibility on that to your stakeholders ASAP and invite them to ask questions of you.

Use that list as an opportunity to challenge assumptions and focus your learning efforts. Be decisive about which questions you can’t afford to answer (or aren’t worth answering) right now - this will save you time in the future.

Use Confidence Intervals

One of the smartest (and accidental) things I ever did on the biggest project I worked on was listing out all of the riskiest parts of the project and give them a percentage rating: from 0-100, how much was that particular area entirely on rails to the point where if I left it unattended it would turn out great with almost no change in approach.

This showed me, for example, that we had done a great job setting up our technical foundation.  The engineers were aligned on not just the architecture but the approach.  However, we hadn’t even begun to test usability, and when we finally did, we realized we had made some big mistakes and assumptions about how players would act within the product. When we finally started that testing, we unearthed much work there to reach our goals. We did that test because I rated that area a 30%

I also brought in a release expert who helped me come to the understanding that the infrastructure, tech, tools, and staff we’d need to release this giant product was in the ~10% range. I had more questions than answers.

Instead of being a slave to a roadmap or plan, I was about to focus on the most significant gaps on the project and address them. Seeing how many gaps there were at times had me bring in outside help & expertise instead of trying to force it through my existing team or ignoring it.

If you’re feeling overwhelmed with how to approach estimation and need some kind of data to work with for now, use this approach. Confidence intervals are one of the surest ways to get a very accurate gut check from yourself and the team on where things are at.

Imagine having a spreadsheet for your team leads that lists every major area of the project and risk and your team’s confidence interval. You’d be much more efficient about where you applied effort and resources.

Action:

Take your list of questions or project areas (ie, technical foundation, audio, UI, team velocity, etc.) and give each line item a confidence interval. This will provide you with insight you can use to focus your efforts. I will be shocked if you don’t have much helpful dialogue within your team from discussing what you come up with.

Closing

Focus on creating loops, answering questions, and understanding confidence intervals in critical areas, and you will be well on your way to having an “uncertainty-busting” approach to making games. The critical thing here is to remember that you want to avoid static thinking as much as possible.  Development ebbs and flows, and it’s the emergent learning, ideas, and answers that come from these loops that will allow you to make the best possible decisions as early as possible. Over-planning and false confidence push those moments until they’re too late for you to do anything about them.

Whenever you’re ready, there are 3 ways we can help you…

—>Courses built by game devs for game devs - check out “Succeeding in Game Production” HERE.

—>Regular deep dives on critical game development topics on the BBG podcast

—>We’ve helped many high-profile game studios save a ton of money & time through building clear vision and leveling up leadership. If you’d like to work with us, please reach out at [email protected].