What Went Wrong? Learning From Past Game Development Postmortems

Anecdote:<p>I'm sitting in an all-hands meeting at a 20-ish person game company I'm working for. We've just had a project canceled. We go around the table doing a post-mortem.<p>When it comes to the producer's turn, he pulls out a Game Developer mag, with a post-mortem of a previous project we shipped. We repeated almost all of the "what went wrong" section.<p>Of course, it didn't seem that way, in the thick of things.<p>OTOH, I used to be a bit of a process evangelist. I read Steve McConnell and Joel before they were popular. It's easy to single out unsuccessful projects and point to all the mistakes they made, but often the successful ones make exactly the same mistakes.<p>There's a moment in the middle of a project when it seems like everything's going wrong, and the constraints are unsatisfiable, and it'll just end in disaster. What you do at that moment can make all the difference. Sometimes just refusing to concede the obvious is enough. Often, it's not.<p>Even much-admired companies like Pixar have their crunch horror stories.

"Another classic error we committed was trying to develop generic tools with a view to possible future productions, rather than tools dedicated to the experience of the game we wanted to create."<p>I wonder if there's a lesson here for programming languages? Kernihan and Ritchie developed C for their needs of the moment (Implementing SpaceWar on a PDP-11) and it became wildly successful as a language. Maybe feedback from actual use generally trumps design up-front for languages?

I've wondered about the usefulness of the "what went wrong" section of the Game Developer postmortems, given that they are all games that <i>actually shipped</i>. It's possible that the "what went wrong" problems are things that might have jeopardized the project had they been worse. But it's also possible that these problems are simply aspects of successful projects, and that trying to fix them would make the project less likely to succeed.<p>For example, a lot of postmortems complain about not spending enough time creating artist tools. Does this mean spending a lot of time on tools will make your project more successful? Or does it mean that all the teams that spent enough time on tools didn't have enough resources to complete their projects (and thus didn't get postmortems)?