|Picture from a solo delta/plus session. A little lonely, but effective!|
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:
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'). 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.
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.
Walking the "Four Corners"
4 Strategies to Help a BIM Zealout. #1 is the Hardest, but Best for You in the Long Run
Like what you read? Signup to get (bim)x In Your Inbox