The old post-mortems in Game Developer magazine were written almost in template form.<p>Went right:
1) Great team/culture
2) Everyone put forth the effort (scheduled crunch)
3) Some amazing techwork or artwork or designwork etc...<p>Went wrong:
1) Didn't anticipate x/y/z
2) Burnout (remember that crunch)?
3) Bad/lazy scheduling and/or capacity planning<p>Kudos to the people who did this at MS but you're looking at tainted data. Most game developers know what really went wrong and do not publicly broadcast it in fear of losing future contracts or publisher trust. In the end the postmortem becomes a soundboard for 'shoutouts' and cheer-leading instead of that raw, unbiased feedback.<p>I've been to all hands post-mortems that were like that and it can get really really ugly.
> <i>9. CONCLUSIONS</i><p>><p>> <i>We find that we were able to identify both best practices and pitfalls
in game development using the information present in the postmortems.
Such information on the development of all kinds of software would be
highly useful too. Therefore we urge the research community to
provide a forum where postmortems on general software development can
be presented, and practitioners to report their retrospective thoughts
in a postmortem.</i><p>><p>> <i>Finally, based on our analysis of the data we
collected, we make a few recommendations to game developers. First,
be sure to practice good risk management techniques. This will help
avoid some of the adverse effects of obstacles that you may encounter
during development. Second, prescribe to an iterative development
process, and utilize prototypes as a method of proving features and
concepts before committing them to your design. Third, don't be
overly ambitious in your design. Be reasonable, and take into account
your schedule and budget before adding something to your design.
Building off of that, don't be overly optimistic with your scheduling.
If you make an estimate that initially feels optimistic to you, don't
give that estimate to your stakeholders. Revisit and reassess your
design to form a better estimation.</i>
I found the Games Outcome Project to be much more rigorous(and anonymous) on the what practices help and hurt gamedev:<p><a href="http://gamasutra.com/blogs/PaulTozour/20141216/232023/The_Game_Outcomes_Project_Part_1_The_Best_and_the_Rest.php" rel="nofollow">http://gamasutra.com/blogs/PaulTozour/20141216/232023/The_Ga...</a>
The recommendations at the end of the pdf seem to be written by captain Obvious. They are so generic they can apply to about ANY project even non gamedev related.
In the past, Gamasutra has also published data indicating correlations between "biggest problems/biggest successes" and marketplace success.<p>The takeaways I remember about that: A good producer matters, a team of a least three people does better than one or two, and experience shipping stuff matters.