In This Chapter
• Purpose of a Postmortem
• Conducting a Postmortem
• Lessons Learned Document
24.1 I
NTRODUCTION
U
sually, postmortems are conducted at the end of the game development
cycle, because they provide closure to the entire development cycle.
They are an opportunity for you and your team to discuss the ups and
downs of the project and how this knowledge can be applied to improving future
projects. It’s also an opportunity to celebrate the game’s completion with each
other. The postmortem must involve feedback from the entire team in order to
be useful. After the actual postmortem meetings are completed, the information
from these discussions is distilled into a Lessons Learned document that outlines
a plan for implementing some changes in the process for the next round of games.
This chapter provides information on why a postmortem is important and how to
successfully conduct one, write up an action plan, and implement changes.
24.2 PURPOSE OF A POSTMORTEM
The main purpose of a postmortem is to learn what methods worked and what
didn’t work during game development. These items are usually focused more
POSTMORTEMS
Chapter 24
384 THE GAME PRODUCTION HANDBOOK, 2/E
on the production process—scheduling, planning, implementing features, and
so on—instead of on the actual design features of the game. Although successes
and failures in the game are discussed in postmortems, they are usually tied to
something that was done correctly or incorrectly in the production process. For
example, if the game is not play-balanced correctly, it could be that time was not
scheduled to do this, or if the character models are getting rave reviews, it could
be that the production process included some validation steps that allowed the
character artists to get the most out of the tools and technology when creating
assets. Also, a postmortem is different from the project reviews and critical stage
analysis discussed in Chapter 18, “Production Techniques,” because they are
focused on how the game development process operated, rather than the actual
content of the game.
Postmortems tend to be overlooked in the development process for a variety
of reasons, such as there is not enough time; it’s not a high priority; or people are
not interested in improving the process (after all, the game got done didn’t it?).
However, postmortems are a vital way to learn from mistakes and validate new
ideas that improve the process. By not doing one, developers are overlooking
the greatest source of concrete information they have on making things more
efficient, less costly, and better on future projects.
In order to extract this knowledge from the team, postmortems should focus
on answering these questions:
Did we achieve the goals of the game? In order to document the an-
swers to this question, you will need to prepare a project overview of what
the original goals were and the goals the game actually fulfilled. For example,
the original goals might have included four character classes for the player
to choose from, and the game actually only has three. The purpose of this
question is not to highlight where the team fell short of the goal, but rather
to evaluate why the goal wasn’t achieved, such as changing scope, shifting
priorities, or limited time. Solutions to these impediments can be examined
and implemented to prevent this on the next game.
Were the project’s schedule, resources, feature set, and quality ex-
pectations realistic for achieving the set goals? When discussing this
question, you will want to bring up concrete examples of where these areas
were properly planned for and areas where they weren’t. This is not an op-
portunity for the team to personally attack others about their shortcomings.
Instead, this question should focus on the facts of what happened to im-
pede to goals of the project. For example, people could say something like
the schedule did not account for bug-fixing the levels, therefore three levels
were cut from the game in order to get the rest of the levels finished, or the
approval process took too long and impacted the amount of time available to
implement a feature.
POSTMORTEMS 385
What went right? What went wrong? This is an opportunity for the team
to relay personal experiences of what worked and didn’t work on the project.
By discussing both the positive and the negative, the team can carry over
expertise to other projects of which procedures to implement and which
ones to avoid. Additionally, if a procedure did not work, solutions can be dis-
cussed for ways to make something different work on the next project with
the same desired results.
What are the lessons we learned? The team examines all the informa-
tion gathered from the previous questions asked and determines the core
lessons learned during development. These lessons should focus on big
picture items, and less on small details. The details can be used as meth-
ods for implementing the lesson learned on the next project. For example,
“communicate deadlines clearly to the team” might be one lesson learned,
whereas the methods for communicating these deadlines (email, status re-
ports, weekly meetings) provide the details on how to accomplish this. The
regular postmortems featured in Game Developer magazine provide some
great examples of lessons learned.
If working on a project that takes more than a year to develop, try to sched-
ule a mini postmortem after each major phase of the project: pre-production,
alpha, beta, and code release. This way, you can continually improve the produc-
tion process, instead of waiting until the next project to make improvements. If
you are working on a project that takes a year or less, you can schedule a single
postmortem at the end. Additionally, encourage people to take notes during
the development process of things to discuss in the postmortem. This will ensure
that the details are not forgotten and can be used to formulate solutions for the
Lessons Learned document.
24.3 CONDUCTING A POSTMORTEM
Preparing for and conducting a postmortem might initially seem like a lot of
work, but the benefits outweigh any inconveniences, especially if the lessons
learned are taken seriously and implemented on the next round of projects.
If you are currently working at a place where postmortems are not done, or they
are done but nothing ever changes, you might want to meet with studio manage-
ment to find out why this is. You can work together to add this valuable tool to
the development process.
There are several different ways of doing a postmortem. Some are fairly
simple and take little time; others can be more involved and time-consuming.
Which method you use depends on how much time there is to do one, how
in-depth the lessons learned are expected to be, and what the overall goals are.
386 THE GAME PRODUCTION HANDBOOK, 2/E
For example, if you are working someplace where a postmortem has never been
done, start off with something uncomplicated so that people can get familiar
with the process. They might be overwhelmed if you try to have a postmortem
that covers every single aspect of the project and takes a few days to complete.
However, a simple postmortem will still help them uncover some basic lessons
that can be applied to the development process. On the other hand, if you are
working someplace that does postmortems on a regular basis and successfully
implements lessons learned, you might want to focus on a more robust postmor-
tem process, as it is likely that your team will benefit from a process that helps
improve more than just the basics.
Several project management books are available that discuss how to conduct a
postmortem. Please consult Appendix C, “Resources,” for a full list. Additionally,
www.projectreview.net, a website maintained by Bonnie Collier, offers a de-
tailed process for conducting a thorough postmortem. Regardless of how you
choose to run your game’s postmortem, there are a few basics to follow.
Involve the Entire Team
The entire team must be involved in the process—QA testers, production per-
sonnel, artists, designers, and engineers. If the team is especially large (more
than 20 people), you might want to first set up departmental postmortems and
then schedule a final postmortem where the entire team gets together. The ben-
efit of having departmental postmortems before the main one is that people can
discuss the positives and negatives of their part of the project, formulate some
new department procedures (such as a format for writing more useful design
documents), and be better prepared to participate in the team postmortem. This
will also prevent the team postmortem from getting bogged down with design,
engineering, and art specific issues, since these issues will have been already
covered. If the team is smaller, you probably don’t need to schedule these de-
partmental postmortems beforehand.
Prepare for the Postmortem
As with project reviews (discussed in Chapter 18, “Production Techniques,”),
proper preparation is essential for getting the most out of the postmortem. Before
scheduling the meeting, gather all the pertinent project information, such as the
original project goals, the actual project goals, deliverable lists, schedules, meet-
ing minutes, change request forms, crunch time data, and anything else that
provides the facts on what happened during the project. Share this information
with the entire team and have them go through it before the meeting.
Establish a postmortem outline and send this to the team a few weeks before
the meeting. They can take notes on what information they can contribute to
POSTMORTEMS 387
the postmortem and be better prepared for the discussion. The outline does not
need to be extremely detailed but should cover the high-level topics that will be
discussed:
■
Did we achieve the goals of the game?
■
Were the project’s schedule, resources, feature set, and quality expectations
realistic for achieving the set goals?
■
What went right? What went wrong?
■
What are the lessons we learned?
Add sample questions under these topics to aid the team members in mak-
ing notes on what they can contribute.
These sample questions should personalize the development experience for
the team members, as they will make better contributions if they are speak-
ing directly from personal experience. For example, ask questions such as the
following:
■
Were your game features completed? What aided or prevented this?
■
Were your tasks appropriately scheduled during the course of the project?
■
Did you understand your role on the project?
■
Were the production pipelines useful to you? How can they be improved?
■
Were you satisfied with your contribution to the game?
■
What process worked the best for you? The worst?
■
What will you do differently on the next project?
Finally, before confirming the time for the meeting (or meetings, if you are
doing departmental postmortems), decide on an appropriate location. If the
postmortem is going to take more than two hours, you might want to consider
having it offsite. This will probably be more comfortable for people, especially
if the team is large, and will prevent them from getting distracted by their work.
Additionally, if the project was especially grueling, an offsite location will pro-
vide a neutral meeting place, and people might feel more comfortable discussing
their positive and negative experiences.
Maintain Focus
When you actually sit down to have the postmortem meeting, keep the team
focused on the goals by establishing the meeting norms discussed in Chapter 18,
“Production Techniques”:
■
Set an agenda
■
Appoint a moderator
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.