How do you best manage risk when creating a game? Using this article and the attached spreadsheet, you can better identify the problem areas in your game and get a sense of whether any decisions you are making actually make business sense.

Risk in Game Development

Ours is a tumultuous industry, rife with unexpected project and studio failures.  There are countless stories of canceled projects, unanticipated multi-year delays, cost overruns, mass layoffs, and unexpected project quality problems.  Often, these surprises come from well-known and well-respected studios with a long and storied history of producing high-quality projects.

On the technology side, we sometimes select platforms and engines poorly, postpone bug fixing until it's too late, build undisciplined technical teams to with inadequate standards and poor coordination, and incur mountains of technical debt while underestimating the risk of avalanche.  On the creative side, we can hire poorly, fail to develop our creative talent or the teamwork they need to flourish, fail to develop a coherent creative vision, or underestimate the costs of major late-stage creative changes.  On the marketing side, we sometimes inadequately analyze our markets and misunderstand which features our customers truly care about. And we take enormous teamwork risks, far too often short-changing priceless talent and underestimating the risk of low morale, teamwork failures, and employee turnover.

On the surface, these all look like completely different problems.  But a closer look shows a common thread underlying many of these project failures: as an industry, we often fail to accurately gauge and manage risk.  We very often make decisions by instinct or guesswork, let our excitement for a project blind us to its faults, or bring too many biases from past experience onto new projects without doing the work to truly analyze and manage the risks inherent in each new project.

Why do we so often fail at assessing and managing risk, and what can we do to fix it?

In 2009, I enrolled in a Penn MSE program co-sponsored by the Wharton School of business, in part to learn better answers to these questions.  While there, I had an unexpected and priceless opportunity to learn Discovery-driven planning ("DDP") directly from its co-inventor, Ian MacMillan, and from Professor Ron Pierantozzi.  After graduating from the program, I used discovery-driven planning to plan the development of the iOS/Android strategy game City Conquest, as discussed in the recent postmortem.

DDP has proven very successful in countless organizations outside the game industry for planning and managing risky and innovative projects.  There is no magic bullet for managing risk, but the DDP planning methodology can help you identify which risks can and should be managed, and can go a long way toward building a risk management focus into an organization, beginning at the very earliest stages of planning.

Nearly all of the ideas in this article are adapted directly from examples by Professors MacMillan and Pierantozzi.  This article is intended only as a brief and simplified introduction to guide the reader through the DDP process.  For readers interested in a more thorough introduction to DDP, we recommend the seminal article from Harvard Business Review and the books Opportunity Engineering and Discovery-Driven Growth.

In this article, I will explain the discovery-driven planning process and illustrate its application to games with an extended freemium game example.  However, bear in mind that DDP can also be used in other many aspects of development, such as planning the development of new technologies such as tools and engines.