The bulk of the [postmortem] should revolve around the "5 wrongs, 5 rights" concept:

Explain what 5 goals, features or aspects of the project went off without a hitch or better than planned. Were there any phases of development that you thought would be much harder than you had planned? Did a new programmer come on the team and inject great ideas or brilliant programming ability into the effort? Did a new technology become widely adopted by consumers that solved a particularly thorny development problem? Did new development tools become available that let you add better graphics or sound? Did you save money in certain ways you hadn't expected? Cut days/weeks/months off the schedule in some way you hadn't expected to? Did the marketing or PR team get some outstanding preview coverage in a consumer magazine?

Explain what 5 goals, features or aspects of the project were problematic or failed completely. Did the lead programmer leave the company halfway throughout the project? Did adapting to new technologies (for example, MMX, DirectX, a new graphics library or AI algorithm) create unanticipated problems for the developers? Did your development tools let you down in some way or not live up to expectations? Did hidden costs creep into the project, and if so, where did they come from? Did the schedule slip for some reason? Was the configuration testing or beta testing cycle problematic for some reason? Did features get axed because of scheduling pressures? Did the lead programmer quit? Did the marketing or PR team misrepresent the game to the public, causing false hopes? Be specific in this regard -- postmortems that accentuate the "what went right" and sugar coat the "what went wrong" sections are dismissed by readers and won't be accepted by our edit staff. Be honest, that's all we are asking.

These postmortems are deemed so significant to other game developers that they're often the cover story on the magazine. I think that's exactly the priority level postmortems should have; if you're not learning from your mistakes, or even better, learning from other people's mistakes, then your next project will have a rocky future at best.

All the postmortems are worthwhile, and you'll surely recognize a lot of the pitfalls and triumphs they describe. Even if you don't care a whit about gaming, it's instructive to read game development postmortems because game development is such a pressure cooker. It's incredibly challenging software engineering, with unclear goals (eg, "fun") under intense deadlines. Every project pathology you're likely to see on your software project has probably already materialized on one or more of these games.