This week I’m working on a web project with teams in India, China, Chicago and San Diego. It gets tricky to keep everyone on track and move to the finishing line in sync.
We’ve been doing this for six months now. One way we’ve managed to improve our productivity – and stay reasonably sane – is to send out a Lesson Learned email towards the end of the project.
Why Lesson Learned?
The purpose of Lesson Learned is to not only to capture what went wrong (because we know this for the most part) but what went right and how to improve on this… and to make sure everyone gets the credit they deserve.
I try to use these to connect us as a team in the same way a football coach would try to galvanize his team.
‘We’re all in this together…’
How to Do Lessons Learned By Email
You can use this sample template format to get started:
I’m sending you this email as you have been part of the [project].
Can you please take 15-20 minutes to provide Lessons Learned feedback by [date].
Use the format and guidelines below to reply to directly to [your name] at [email address].
If you want, I will keep your feedback response anonymous unless you want otherwise. This is to ensure you are comfortable with giving your feedback on problems or challenges for our team.
It is important we get your perspective on what was effective as it will contribute to how we solve our challenges and identify what needs to be improved.
Share Your Feedback
Please use a priority of 1-5 (one being least significant/impact, 5 being highest).
This gives us a quantitative evaluation on what items to address first and which lessons have had the greatest impact.
Please do NOT mention individuals by name (unless you want to give them credit of some sort).
Stay positive and discuss how our project/solution can be improved going forward
What Went Well
Give some examples of what worked.
What Needed to be Improved?
Give some examples of what needs to be improved.
What caused the Problem?
Give some examples.
What Impact did this have on this project?
Give some examples.
Please add your comments on areas such as:
- Inter-department communications
- Software Development Processes
- Technical Documentation Process
- Technical Environment
- Business Proposal Development and Procurement
- Salary / Overtime pay
- Software Testing Process
- Other areas not mentioned above
Make Lessons Learned Work
I find that this works if the information is accurate, balanced, and actionable.
For me, this means listening to what others say, gathering their opinions and then sharing it – and staying neutral.
It can be hard not to skew the feedback to make yourself look good or rundown other parties, even very slightly but you have to avoid this. Otherwise, you lose all trust.
The benefit with Lessons Learned sessions is not to blame others but to share insights that they may have overlooked during the project, so things run that bit smoother the next time around.
What else would you add?