14
\$\begingroup\$

After the game is done (either shipped or the project was canned), what is the best way to make the post mortem, so that it maximizes the chances to never make the same mistakes again?

  1. How do you gather all the needed informations from the team?
  2. How do you condense them in the final postmortem?
  3. How do you avoid to make the same mistakes in the following project?
\$\endgroup\$

3 Answers 3

10
\$\begingroup\$

You're gaining valuable insight as you work through the process. For any good business man that works on a project it's fairly easy to tear your project to pieces when analyzing what you did wrong. Figuring out want went right is a little harder.

How I would approach a thorough postmortem

Get All Perspectives in Writing
Ask each team member to write a few pages on project observations. Instead of randomly laying a trail for them to fulfill I would ask exact questions that you want to know about. You can supplement this with a meeting, but I rather get someones sole attention without distraction.

The most obvious questions would be

  • List your top 5 items you feel went right with the project?
  • List your top 5 items you feel went wrong with the project?

I would supplement those questions with specific questions relating to the team and project that you personally want to know from a management position.

  • How did you feel about working with Box2D instead of Chipmunk? Would you use (x) again?
  • Do you feel the project management was able to do x, y, and z for you?

Fail Early, Fail Often
Well, it is pretty hard to 'fail early' when your project is out of the door. Hopefully the feedback you gain from the above will shed light on processes that may have been pretty dark to you.

There are problems that you will run against that will sting pretty bad. It'll be pretty difficult to just forget those.

To make sure that you don't forget the problem areas it could be handy to write a 'Core Value' type list that you keep at arms reach. Keep them available for others to see and for you to see. When the your next project starts I might be inclined to bring some of these to the table to get other people's perspectives. If you have new eyes on the project you might get feedback that could shed new light on solving a particular issue.

As long as you're aware, and you keep your problems in the light, you're bound to solve those issues.

Write It
Grab all of the writings and bring it all together.

  1. Introduction to the project, goals, and anything you feel like sharing about the project process
  2. Top 5 - What went right?
  3. Top 5 - What went wrong?
  4. Conclusion... Bringing it to the end.
\$\endgroup\$
2
  • 1
    \$\begingroup\$ +1 for the "what went right?" It's too easy to break what you did well when trying to fix what you did badly. \$\endgroup\$
    – tenpn
    Commented Jul 20, 2010 at 7:44
  • \$\begingroup\$ Very good answer! :) \$\endgroup\$
    – user274
    Commented Jul 20, 2010 at 8:12
1
\$\begingroup\$

Most of the postmortems I've read seem to follow a format of:

  • What we did
  • What went well
  • What could have gone better
  • Conclusion (what was learned, and will be applied next time)

I'd get all the people involved on the project to toss in their $0.02 and see what they have to say about those things, then compile everything into one big, exciting to read document.

I guess in answer to your questions: 1. How do you gather all the needed informations from the team? Ask them. Email, sit down and chat with them individually and as a team.

  1. How do you condense them in the final postmortem? Lump together common responses. Chances are you will be able to recognize general trends (ie: people having the same issues). Focus on the big/important ones.

  2. How do you avoid to make the same mistakes in the following project? That's a bit of a tricky one. Maybe write up a single 8x11" sheet of paper to pin in your cubicle as a reminder to avoid those specific previous mistakes? I've got a few sticky notes like that just below my monitors, and they seem to do a decent job of reminding me to do certain things.

\$\endgroup\$
0
\$\begingroup\$

How do you gather all the needed informations from the team?

I like to have everyone write down their list privately first. On the last project I did a post-mortem for, we had four sections: 1) Things that went right, because we did things in an awesome way 2) Things that went wrong, because we screwed up 3) Things that went right from our partners (outsourcing houses, publishers, etc.) 4) Things that went wrong with our partners because THEY screwed up

The first two help us to adjust our own behavior. The last two help us to pick better partners (or manage our existing ones better) next time.

How do you condense them in the final postmortem?

Have everyone email their lists to one sucker^H^H^H^H^H^H volunteer, who then condenses and anonymizes the lists. The collated list is then sent to everyone and discussed.

How do you avoid to make the same mistakes in the following project?

In my experience, you don't :) In seriousness, when I start a job at a new game company, the first thing I take a look at is the previous post-mortems (if they have them on file somewhere). Usually I see common themes throughout all projects, which tells me ahead of time what kinds of challenges to expect on the current one. If I were running my own studio, my first instinct would be to start the kickoff of each new project with a re-reading of previous post-mortems, and a discussion of how not to do the same dumb things a fifth time... and then re-visit the hot-button post-mortem issues at each milestone in the project.

\$\endgroup\$

You must log in to answer this question.