/var/www/apps/collegelist/repos/collegelist/trunk/collegelist/tmp/scratch4/3170098.

doc

POST IMPLEMENTATION REVIEW - PROJECT DEBRIEFING

for
Projects, Upgrades or Releases

Purpose – Conduct a facilitated, documented discussion of staff that participated in the

development and implementation of a system or upgrade to a system. It should be
conducted several weeks after implementation. The intent is to identify how the process
can be improved in the future. The focus is what worked well, what didn't, steps to avoid
repeating problems in the future, and identification of steps to continue following to help
ensure success.
Attendees - Include all users who were involved in the design, testing, and
implementation process. Primary users from departments should attend, not everyone
who was trained. Also, at least one, preferably several primary developers should attend
to answer questions about functionality and to hear the comments regarding
improvements to the process in the future.
Process – Schedule a review session for about 1- 1.5 hours. Before the meeting, send a
brief message indicating the project to be reviewed and the process to be followed. Begin
the session by explaining the objective of the session, ground rules/guiding principles and
expected outcome. Have a team member quickly review the project, upgrade or release
that was recently implemented.
Have a note taker and a facilitator.
The facilitator will guide the discussion asking the attendees to write items on yellow
sticky notes What Worked Well?
For each of the following categories:
Requirements Definition/Scope
Design
Development
Test
Deployment
Communication
The attendees then post their comments on the board under the appropriate category.
Then review out loud what went well, asking for clarification where needed and group
like items around themes.
Then ask those attending to write down What can we do better the next time? in each
of the same categories. These are also discussed out loud and ideas for implementing
change are briefly discussed.
Finally ask the group What do you want to share with your peers? This would include
processes that went well and pitfalls to avoid. This information will be shared with other
project teams and the HR and Financial Computing Committee.
The meeting is then adjourned.

1
/var/www/apps/collegelist/repos/collegelist/trunk/collegelist/tmp/scratch4/3170098.doc

Tips - Keep the conversation light and be sure that everyone understands the purpose of
the meeting: to improve the process, not to complain. The meeting should last no longer
than 1 hour to prevent conversations from running on.
Follow-up - The comments should be taken very seriously and followed up on, another
reason for developer participation, to show that we are serious. A summary of the
discussion will be sent to the participants. The recipients should focus on suggestions of
what to avoid in the future and what changes can improve the process. The information
to share with peers will be sent to other project teams and the HR and Financial
Computing Committee.