388 THE GAME PRODUCTION HANDBOOK, 2/E
Record minutes
Follow up on action items
The agenda can be based on the outline sent to the team beforehand. The
moderator should be someone neutral, ideally someone not involved in the proj-
ect. If you are doing a thorough postmortem or do not have an experienced mod-
erator, you might want to consider hiring an external one. The benefit is that this
person knows how to properly facilitate discussion in this forum and can keep
the meeting focused and running efficiently. The minutes should be recorded
and published to everyone, but these do not take place of the Lessons Learned
document that is produced as the final deliverable.
Although it is inevitable that many negatives will be discussed during the
postmortem, the overall experience should be a positive one for everyone in-
volved. Establish some participation guidelines in order to keep the mood posi-
tive and the criticism constructive. Some basic guidelines are as follows:
Be professional at all times and don’t make personal comments about other
team members.
Don’t censor or criticize other people’s comments.
Maintain a positive attitude geared toward improving things for the future.
Take the opportunity to show appreciation for the work you did together as
a team.
Other guidelines can be added as necessary, and it is useful to post these in
a prominent place in the meeting room.
After the goals are reinforced and people are reminded of the participation
guidelines, you are ready to begin the actual meeting. Follow the agenda for
each discussion point and be sure to get everyone to participate. Some team
members are naturally more outspoken than others, and if not controlled, these
people will end up dominating the meeting and deterring the less vocal people
from fully participating. The moderator can control the information flow by
calling on people to speak and gently cutting off people who have gotten off
topic. If the group is small enough, you can start with the first question on the
agenda and get feedback from everyone by calling on them individually. If the
team is larger, be aware of who has already spoken and who has not said any-
thing. Overall, keep the meeting focused on the agenda and the set goals.
24.4 LESSONS LEARNED DOCUMENT
In addition to the postmortem meeting minutes, the Lessons Learned document
is a written deliverable of the postmortem process. As discussed earlier in this
POSTMORTEMS 389
chapter, the lessons learned focus on big picture items that can be applied to
future projects. Ultimately, the Lessons Learned document will be published to
the team, the studio, and perhaps even the publisher so that everyone can ben-
efit from your team’s experiences.
Writing the Lessons Learned document should not take too much time,
especially if the notes from the postmortem are detailed and accurate. The
lessons that will be included in the document will have been determined in
the postmortem meeting. The author of the document can be a single person,
like the producer, or several authors, such as the leads, who can contribute to
each section to speed up the writing process.
Limit the number of lessons learned in the document to five. Anything
more than that is daunting to implement, thereby reducing the effectiveness of
publishing the lessons in the first place. Focus on lessons that have the highest
probability of being implemented. For example, one lesson might be “sched-
ule time for risk assessment after each phase of the project.” This is some-
thing that can be implemented fairly easily and does not require any upfront
monetary investment. Conversely, a lesson that states, “Send everyone on team
for training in Team Software Process,” might not actually have a chance of
being implemented due to schedule and budget constraints. However, lessons
like these can be implemented if the company is committed to it, so gear each
Lessons Learned document toward what the company can willingly commit to
implementing.
Provide an example of why the lessons learned are important. This is where
the team’s personal experience really helps define why change in a certain area
is necessary. If scheduling time for risk assessment is a lesson, include the ex-
ample that makes this important. For example, if a risk assessment had been
done after the pre-production phase, the team would have realized that the per-
sonnel needed to implement the graphics features would not be available until
later in the project, putting the level production at a huge risk for missing the
beta deadline.
When the document is written, have it reviewed by the team, make any
necessary corrections, and then publish it to the rest of the studio. You can
publish it by posting it on the company website, emailing it to everyone, or shar-
ing it in a specified place on the network. If your studio has multiple postmor-
tems, centralize their location so they are readily accessible to everyone.
In order to ensure that lessons are being implemented, follow up with
the team on what changes they’ve made. For example, before beginning
production on the next project, sit down with the core team, review the les-
sons learned from the last project, and formulate an action plan to imple-
ment them. This action plan can become one of the pre-production project
deliverables.
390 THE GAME PRODUCTION HANDBOOK, 2/E
24.5 CHAPTER SUMMARY
When the team has worked hard to complete a project over the course of six
months or three years, a postmortem is necessary to provide closure to the
development process. A postmortem is an opportunity for the team to gather
one final time to congratulate each other on a job well done and to learn from
mistakes.
A successful postmortem does not need to pick apart every little thing that
went wrong on a game, but rather should focus on things that went well and
things that can be improved for future projects. This chapter discussed how to
run a successful postmortem and determine lessons that can be applied to other
projects.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.145.37.126