4 Strategies for Lessons Learned That Won't Monopolize Your Time

Picture from a solo delta/plus session. A little lonely, but effective!
It's so interesting that when we focus on a specific topic, we start to see it and hear it everywhere. A few months ago, Tocci's virtual design & construction (VDC) department decided we needed a more systematic way tof collect, share, and implement 'lessons learned'. And since then, I have noticed a variety of ideas, strategies, and tools. 

It is important to gather lessons learned on all types of projects, initiatives, and programs. It is especially important when using new processes - so perhaps, use of disruptive technology and processes! At the same time, it is really hard to do consistently, since we are all so busy doing the work of the project.

Given that, I thought I would share some of the strategies I've used or recently heard:

Delta/Plus Sessions

This is a strategy I really like to use. After a specific activity or process, we gather those involved in the process to identify the pluses ('what worked') and the deltas ('what didn't'). While I (and many others I'm sure) was originally introduced to these sessions through various lean literature and conversations, I recently also started using the simpler language of 'what worked' and 'what didn't' (courtesy of John Wachter, of Wachter Consulting).

Since lessons learned tend to have a negative connotation, I like requiring focus on the pluses - it can identify successful strategies that may benefit similar projects or processes. First we brainstorm individually on red and green post-its, then we share with the group and cluster them to identify common reflections. We typically select several items to focus on and identify:
  • resolutions to the 'what didn't'
  • ways to codify the 'what worked'
Best Practices Lunch and Learn
I had lunch with an architect a few weeks ago, and he shared the method his firm uses. Basically, they pick a topic (i.e. egress plans, LEED tracking, or coordination with structure) and gather related assets from a number  of recent projects. At the lunch and learn, attendees (whoever is available) divide up into facilitated teams review and discuss the topic, using the materials available as triggers for 'what worked' and 'what didn't'. While they don't document all of the their discussions for central storage and access, they find it an effective way for more junior staff to learn from more experienced staff.


Tech Notes

One of my team members has termed his lessons learned methodology as "tech notes". Basically, he saves miscellaneous documentation related to a particular issue (i.e. cooling tower replacement or as-built BIM development) in a single Word document - emails, sketches, RFIs, pictures, and other items. At the end of the process, he can review everything he has, and identify lessons learned and strategies for future initiatives. I see a few benefits to this:
  • It is easy to implement as an individual, so you don't have to worry about spearheading a large initiative or getting corporate approval.
  • Because its just capturing work product, it doesn't take up a significant amount of time during the process or project. You don't have to worry about it taking away from results. 
  • When you are ready to summarize lessons learned, the tech notes serve as a reminder for things you may have forgotten.

Lessons Learned Log

I was doing some research on databases and templates for lessons learned and found a really simple template at Project Management Doc. I haven't had a chance to implement it yet, but I love the log, recommended by Project Management Docs to communicate lessons learned in a consistent manner. I can see maintaining one as an individual, department, or project team.

How are you gathering best practices and lessons learned? How do you share them? Leave a note in the comments or tweet to me.


No comments: