We’ve been focusing on the Game Outcomes Project this week, which surveyed hundreds of developers about various factors in their completed projects, and weighed them against multiple indicators of success. In the third part of the published series, the project talks about a hot-button issue: Crunch.

Crunch picture from Shutterstock

Crunch

We’ve always had a moral objection to crunch. We’ve always known it’s there, and it’s always been a point of contention, to the point of spouses of employees speaking out, and even forming organisations to get things fixed.

But data from the Game Outcomes Project has shown that forced crunch, very clearly and empirically, hinders the success of game development. The table below shows how various crunch factors correlate with success, positively or negatively.

Crunch picture by Game Outcomes Project

We know it’s bad. But until now, it’s been seen as an unavoidable evil. Even the best managers, some would say, can’t avoid crunch towards the end of the project.

Which is why empirical evidence like this is so important. This is now the best data we have on the subject, and there’s literally no way you can point to that and make crunch look good. If someone tried to make out how they’d be the magical exception to the rule (after allowing the production to get to that point in the first place), they’d just look silly.

Crunch. Not even once.

Design direction

In the category of changing schedules and direction, the biggest factor that hurt projects seems to be shifting goals, especially when the reasoning for these aren’t communicated to stakeholders. As Paul Tozour points out on the blog, when those changed did occur, “participation of all stakeholders in the decision to make changes, and clear communication and justification of those changes and the reasons for them, clearly mitigated the damage.”

What comes as a surprise is that the original design document doesn’t seem to correlate at all with success, yet it seems like vision is important, as is making sure everyone is across that vision and having good, well-communicated reasons for deviating from it.

Other negative factors

Some other factors that had standout negative effects on projects were when team members would work for weeks at a time without any sort of feedback, high staff turnovers (no surprise there), and an unwillingness from management to take the creative ideas coming from below on board. Developers whose creativity wasn’t valued or encouraged was quite a clear indicator of a project doing poorly.

Conflict resolution also played a big part. Both arguments about game design and general disagreements, while occurring in every workplace, were much more toxic if not resolved, and a lack of respect and highly political offices strongly correlated with failure. That might seem like common sense to most of us, but it’s probably something a lot of managers still need to hear.

The last indicator of failure was a major technological revamp mid-production, likely requiring the team to re-skill and adapt, and probably double up on some work to bring the rest of the game up to the new tech’s standard.

You can find a much more detailed account of these issues, as well as the full series, over on the Game Outcomes Project blog.