1. Your bug database is growing out of control
I'm not a fan of bug databases to begin with. They are often rugs to sweep dirt under, and that dirt gets more expensive to clean over time. All that debt has to be paid off, and it's often paid off with crunch and compromise. We should be spending time at the end fine-tuning the experience of the game, not making it barely shippable.
2. You Don't See the Big Picture
Often, especially on large games, individual developers don't understand the game they are working on. It's all in the head of some lead designer, who might even be in a different city. Without a shared vision, moving your game forward becomes like pulling a wagon with a hundred harnessed cats. Chaos ensues.
3. Gantt Charts
Detailed Gantt charts often just serve as project management theater. A complex, graphical chart can often placate a publisher. Not that it's terrible to think about the complexities of work and dependencies, but these artifacts, adopted from manufacturing, aren't well suited for creative work. For one, they don't lend themselves to change very well. The one thing I always look out for are Gantt charts that magically slope downward off in the future when some magical burst of productivity is forecasted, which brings us to the next sign.
4. Wishful Thinking
I'm an optimist, but it usually takes the form of "yes, I'm positive something will go wrong!" Projects should embrace risk. It's more important than task management. Problems do not solve themselves and that reassuring management reserve set aside for problems will probably be gone by the time it's needed. If the game is not fun and on track now, it's unlikely it will suddenly become so "someday."
5. Building Final Content Based on Unproven Technology
This is probably the most expensive one. Technical promises and their schedules are often not worth the electrons used to store them in the project management tool. Even console manufacturers are guilty of this (who remembers the "Emotion Engine"?). If you are creating final, shippable content using budgets (graphics, physics, AI, etc.) that are beyond what your current engine can do, it's a good sign you'll be redoing all that work, in crunch, again.
6. Management "Tells"
As with poker, there are some tells that managers show, which are signs that there is trouble.
- Mandated crunch. Scheduled crunch often means more is coming. It's panic time.
- Moving people between projects to speed things up. This always slows things down. You know why.
- Sudden micromanagement. I'm all for management being engaged daily with developers and communicating more, but when it instantly ramps up, they're worried.
This might sound a bit negative, but game teams get into trouble all the time, and this list could be much more extensive. Identifying the signs early on is the first step in solving them.
Well-proven solutions to these problems exist, but they are not easy. They involve changing approaches to how we think of game development and stakeholders. We need to focus on the game first and the project second. That requires courage from leadership and developers.