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.



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.


Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.