This document has two parts. The first part is a list of categorized questions designed to stimulate thought and discussion about how well things went during the previous project milestone. The second part is an empty document, with headings, that you can use as an outline for your own postmortems. The outline is not meant to be comprehensive but is meant to serve as a starting point for your postmortems. Not all questions or sections will necessarily apply to every project, so use those areas you believe are most relevant.
These questions are meant to generate discussion about what went well, what the team struggled with during the milestone just reached, and what the team would do differently moving toward the next milestone.
It helps to distribute these questions to the team before the postmortem meeting, to give team members a chance to think through and document their responses beforehand.
n Were the group goals clear to you?
n Were the marketing goals clear to you?
n Were the development goals clear to you?
n How complete do you think the planning was before the actual commencement of work?
n How could planning be improved?
n What recommendations would you make for the planning process for the next release?
n How can we improve our methods of resource planning?
n Were there enough resources assigned to the project, given the schedule constraints?
n What could have been done to prevent resource overload?
n Do you think resources were managed effectively once the project started?
n Was the schedule realistic?
n Was the schedule detailed enough?
n Looking over the schedule, which tasks could you have estimated better and how?
n Did having a series of milestones help in making and monitoring the schedule?
n What were the biggest obstacles to meeting the scheduled dates?
n How was project progress measured? Was this method adequate? How could it be improved?
n Was contingency planning apparent? How can we improve our contingency planning for the next release?
n How could scheduling have been done better or been made more useful?
n What would you change in developing future schedules?
n How were changes managed late in the cycle?
n Were the trade-offs between schedule and features handled well?
n Were there issues in the functional design and ownership?
n Were there issues in the architectural design and ownership?
n Were there issues involved in using components or with code sharing? How could this be done more effectively?
n Were there issues in test interaction?
n Were there issues in test case design and coverage?
n Were there enough testers?
n Was the quality of the product we shipped acceptable?
n Did we work well with all of the testers?
n Was communication in your group handled efficiently/effectively?
n Was communication between groups handled efficiently/effectively?
n Was program management effective in disseminating information?
n Was program management effective in resolving issues?
n Was the e-mail alias [eGroup in our case] usage effective? How could the aliases be better set up to improve communication?
n Were the status meetings effective?
n Was communication with the external groups (component suppliers, content suppliers, OEMs, support, international) effective?
Here are some tasks to do in advance of the meeting.
o Send out copies of previous postmortem results for review, if there are any.
o Ask team members to send ahead issues they would like to discuss at the meeting.
o Send out an agenda with a list of potential topics, if you have any.
o Reserve a large room. Tape flipchart paper to the walls, and write down the topics you already know about. Make sure you have markers for writing comments, ideas, and suggestions on the flipcharts.
Here are some tips for how to conduct the postmortem meeting. If, during the meeting, you wish to contribute to the discussion, have someone else record your comments.
o Set the stage for productivity by explaining that the meeting will be conducted in a blame-free atmosphere.
o Ask team members for any issues they want to discuss that were not sent to you before the meeting. Add those to the topics already posted.
o Explain that you’re interested in listing things that went right as well as things that went wrong.
o Review and rank all of the issues to be discussed.
o Starting with the top issue, discuss and record what went wrong and what went right in each case.
o When discussing items concerning what went wrong, stop the discussion after five to seven minutes, and ask for suggestions about what to do differently in the future.
o Check that all functional groups have contributed to each issue. You might need to ask people to offer an opinion.
o Save time at the end of the meeting to prioritize recommendations and assign owners if you can.
Here are some tips for what to do after the meeting.
o Send written notes on the discussion to all attendees and other interested parties.
o Document the recommendations.
o Be sure to refer to the recommendations in future project meetings so people can track progress.
excerpt from the MS Solutions Framework / Feb. 2000