| SUKEE TEA TIME |
|
We do not learn from experience, we learn from reflecting on experience. - John Dewey  A project retrospective is a process recommended during the project closure for post-project review. It's a dedicated time for the project team and stakeholders to discuss what went well, what didn't, and any lessons learned to improve in the future. The meeting should be scheduled right after the project's completion.
The project manager can start by reminding everyone of the purpose and benefits of the project. Requesting business users to demonstrate the result is usually robust and motivating. Then, demand the project team to look backward and contemplate the events leading to the outcome. The team can identify the significant events and analyze the events' root causes. The review should further revisit the risks and issues which can be used to update the organization's risk register for future guidance. Going through the project plan, where the significant events are recorded and highlighted at the beginning of the meeting, usually is effective. After the preparation, the team discussion can then focus on what worked well and what didn't and look for improvements to help the team do better in the future. An example plan can be summarized as follows :
Using the @kanban board in a Quip document has been proven effective tool in facilitating the discussion, where the team members can easily add new cards for feedback, vote for the result, or add thoughts using the comments. "Nobody looks at the feedback! " Last but not least, we would avoid this impression for our practice. It's essential to add the feedback review to our retrospective process, where the project manager and development managers sit down to review the feedback and decide the necessary follow-ups. Them, send an email to the team to update the review result. With this, the team is more motivated to participate next time, and the retrospective efforts can lead to a real impact. References
0 Comments
Leave a Reply. |