What 20 Years of Game Postmortems Reveal: The Research, Summarized

For more than two decades, developers have published postmortems of their games: honest accounts of what went right and what went wrong, first in Game Developer magazine and then on Gamasutra, now Game Developer. Taken together, they are the closest thing the industry has to a public database of how projects succeed and fail.

Researchers have analyzed that database systematically. This is a summary of what they found, and what it means for anyone running production.

The studies

The postmortems in these studies came mainly from Gamasutra, so they skew toward games that shipped and developers willing to write about them. Keep that in mind; the findings are still remarkably consistent.

The problems are mostly about people, not technology

The earliest study, of 20 postmortems, concluded that game development suffers mostly from management problems rather than technical ones, and that the most common were scope that was unrealistic or too ambitious, feature creep, and cutting features. Twelve years and 200 postmortems later, the largest study reached a similar conclusion: most root causes were related to people, not technologies.

Here are the ten most common root causes in that 200-postmortem study:

Only one of the ten is primarily technical. Insufficient workforce, the most common, usually came down to budget, weak planning or the difficulty of hiring the right skills: too few people for the work, or one person carrying too many roles.

What went wrong, and what went right

The 155-postmortem study counted how often each category appeared in the “what went wrong” and “what went right” sections.

The details behind those numbers are where the lessons are:

• Obstacles often came from newly formed teams that did not yet work well together. Half of small teams listed obstacles as something that went wrong, against about a quarter of large teams.
• Schedule problems came from estimation and optimistic scheduling, and from design changes late in development.
• Development process went wrong most often when teams started production without enough planning, and in at least one case because nobody was dedicated to project management and the lead programmer carried it on top of everything else.
• Game design failures were usually over-ambition: features that each looked doable but added up to far more work than the schedule held.

The “went right” side is the mirror image. Teams that praised their process had planned before production, built prototypes as proof of concept, often grew those prototypes into the game, and iterated. Teams that praised their design talked about a clear vision and a strong hook.

What changed over two decades

The 200-postmortem study tracked problem types from 1997 to 2019:

• Management problems declined over the years, while business problems grew.
• Production problems stayed constant.
• Technical and game design problems declined, design problems only in the last decade.
• Team problems increased in the last decade.
• Marketing problems grew more than any other type, as games moved from magazines to forums, social media, storefronts and streamers, and as the market saturated.
• Feature creep became less common over time.

On crunch, the 78-postmortem study found it mentioned in 45% of postmortems, and more often at small studios (54%) than at micro (33%) or medium-sized ones (36%). In the 200-postmortem study, mentions of crunch fell after 2015. Postmortems are written for publication, so fewer mentions may reflect what developers are willing to write as much as what happened.

What producers should take from this

Each of the most common failure modes maps to a check you can run on your own project, early:

1. Staff to the plan, not the hope. If the plan needs more people than you have, the plan is wrong. Insufficient workforce is the single most common root cause.
2. Estimate from the bottom up, and compare with actuals. Underestimation and optimistic schedules show up in every study. Hold explicit buffer before major gates; see buffer time in game schedules.
3. Write the vision down early. Unclear vision and misaligned teams are both top-ten causes. If team members carry different pictures of the game, you will find out during production, at the most expensive moment.
4. Treat marketing as production work. It is the fastest-growing problem type. Give it an owner, a plan and milestones, not leftover time at the end. Marketing an indie game on a budget covers where to start.
5. Prove the fun before full production. Lack of fun is a top-ten cause, and prototyping is a top reason process went right.
6. Give new teams extra risk management. Small and newly formed teams report obstacles far more often. Keep a risk register and review it on a schedule.
7. Budget for tools. Inadequate or missing tools appear in the top ten, and they are usually cheaper to fix than the time they waste.

For the practitioner view of the same patterns, see why game projects fail, and to run a useful postmortem on your own project, see a game studio postmortem process that works.

Sources

• Fábio Petrillo, Marcelo Pimenta, Francisco Trindade and Carlos Dietrich, “What went wrong? A survey of problems in game development”, Computers in Entertainment, 2009.
• Michael Washburn, Pavithra Sathiyanarayanan, Meiyappan Nagappan, Thomas Zimmermann and Christian Bird, “What went right and what went wrong: an analysis of 155 postmortems from game development”, ICSE 2016.
• Edholm, Lidström, Steghöfer and Burden, “Crunch time: The reasons and effects of unpaid overtime in the games industry”, ICSE 2017, as summarized by Politowski et al.
• Cristiano Politowski, Fabio Petrillo, Gabriel C. Ullmann and Yann-Gaël Guéhéneuc, “Game industry problems: An extensive analysis of the gray literature”, Information and Software Technology, 2021.