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.