Lessons Learned for Traditional Projects Are Still a Waste of Time

Over the last few months I have been writing about how to improve team retrospectives.  This has been mostly focused on Agile teams.  Recently I've been asked to facilitate a "retrospective" for a traditional project.  I remembered that a few years back, I wrote about why I felt that traditional lessons learned for projects were a waste of time.  My thinking on this topic is still the same - I still feel like those traditional lessons learned activities are a huge waste of time.

The genesis of my 2012 post was a negative reaction to an article posted in Projects at Work written byJohn D'Entremont, PMP and titled Learn your Lessons.  This is a summary of my thoughts on the topic as I prepare to conduct a retrospective for a traditional project. 

My main complaint about traditional lessons learned meetings is that they are usually focused on assigning blame rather than on learning something and applying it to improve future work.  So I am generally skeptical when someone even asks for a lessons learned or post mortem.  I am going to speak more about how to conduct a blame-free retrospective in an upcoming blog post.  For now, let's focus on getting something useful from the lessons learned meeting. 

Teams that are able to avoid the blame game often wind up struggling with applying the lessons learned to future work.  Gathering the lessons learned is rarely the challenge.  We often collect lots of lessons about what did not go well.  We just don't do anything useful with the information.   I don't believe that you should waste the time and effort on "gathering" if you don't have a process for using them.  Which relates to one of my favorite Agile principles.

"Simplicity - the art of maximizing work not done - is essential."

We should not do any work that doesn't need to be done.  We should not spend the time collecting lessons learned if we don't have a use for it, or a systematic way to incorporate them, leverage them, or make them part of the team or organization's collective knowledge. 

Producing a lessons learned write-up that doesn't have an immediate purpose is incomplete work or waste.  It will be a task later for someone to retrieve, dust off, analyze, and determine a way to use this interim work product.  And like other types of inventory, incomplete work that remains unconsumed gets stale and spoils.

I know that many of you are thinking, but we do have a plan for how we will use our collection of lessons learned.  I've heard a lot of approaches to this, and tried many myself, and I just don't think that any of them are good:

  • Posting it to SharePoint/on the shared drive/team Wiki/Confluence/Lotus Notes.  This doesn't work.  Posting things in Sharepoint is the rough equivalent of printing it, boxing it up, and sending it to Iron Mountain for storage.  Hey, why not send it to the microfilm or microfiche department!  Or fax it to yourself so that you have a copy.  (See rant below for more on Sharepoint). 
  • Emailing your colleagues doesn't work either.  They are busy and frankly they don't have time or interest in your lessons learned; they won't even bother to open your email let alone open your elegantly formatted attachment.  Plus, their .NET development project is completely different than your failed SAP or mobile apps project.
  • Sharing them at the next department or information sharing meeting doesn't work. Yawn.  Nobody cares - see previous point.
  • "Hey, let's start off all new projects with a review of the learnings from all the recent department projects."  This sounds like a promising idea but, like, is this really going to happen?  Many new project teams are behind before they start and are often discouraged from planning so they can get right to the work.  How many of them are going to pause, go back and find all the lessons learned, determine what applies, and start with that?

RANT - One phrase I hear that drives me bonkers is "It's posted in SharePoint!" DON'T BE CRAZY, EVERYTHING IS POSTED IN SHAREPOINT! I think it is safe to say that all of the information in WikiPedia is dwarfed by the information that is in SharePoint. The question is, is the information retrievable when I need it? Will I get the correct version? Do I know where to locate it when I need it? Do I have permission to access it? Is the time spent searching for the right information worth it in terms of return? Stop with the SharePoint comments already, nobody goes there to find ANY organizational learning, let alone your lessons learned from the failed SAP implementation."

I also don't agree with the approach to tie lessons learned to the end of project lifecycle phases.  If you only perform initiation or planning once per project, why bother to do a post-mortem after the phase?  It's not going to help that project. 

Chances are, your lessons learned aren't going to help the next project either because the next project will be different in some way.  You aren't going to implement SAP again at your company.  (Unless you are SAP Consulting and even then, I think the track record for applying lessons learned on SAP Implementations speaks for itself.)  The definition of project includes the word "unique" for a reason - project are fundamentally different!

There is an excellent white paper on the Papercut PM which demonstrates this point very well.  "This is why we can't have nice things: A Project Risk Retrospective", talks about the 1st and 2nd projects to build the Panama Canal.  The first unsuccessful initiative was led by experienced French construction lead Ferdinand De Lesseps.  De Lesseps had the benefit of successfully completing the Suez Canal project.  The second Panama Canal project was led by US General George Goethals.  Goethals had the lessons learned from the prior French-led project.  The lessons learned were valuable precisely because they were from nearly the same project, not a similar one!

"De Lesseps had no idea of what awaited him in Panama. While he had previously built the Suez Canal, the geographical environment at the Egyptian work site was flat and dry with marvelous visibility. The Panamanian rainforest was the exact opposite—much of De Lesseps’ previous work in Egypt proved irrelevant in tropical conditions. Goethals, on the other hand, had the benefit of the previous French failure. All of the lessons of “what not to do” were littered across the Central American countryside for anyone who wanted to look. Goethals should rightly be praised for seeking this information, but had this analogue input to his plans been absent, his results may have been very different."

There is an Agile principle that speaks to the retrospective process.

"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

Regular intervals doesn't mean the end of the project.  It means throughout.  Stay tuned not only for ideas on how to eliminate the blame game, but also to make lessons learned during a project effective.

Your thoughts?

 

By Anthony Mersino | Thursday, August 13, 2015

 

About Anthony Mersino

Anthony is passionate about helping technology teams THRIVE and organizations TRANSFORM.  He loves partnering with organizations to help teams with Agile thinking and the Scrum Framework.  He teaches Agile and Scrum as well as the cultural elements that are necessary for an organization to gain true business agility. Anthony has  authored numerous articles and two books: Agile Project Management, and Emotional Intelligence for Project Managers.

 

RELATED POSTS

How to Improve Your Retrospectives Part 1

FASTER! A Guide to Speeding Up Your Next Retrospective

Lessons Learned for Traditional Projects Are Still a Waste of Time

Comments

Spot on as always Anthony. For me, the retrospective has become the most important driver of our team's ongoing success. I cannot fathom where we would be if we waited until the end of an iteration (6 two week sprints) to look back and discuss lessons learned. One of the key aspects of Agile is reducing the cost of failure by failing early and fixing early. The cost of a mistake grows seemingly exponentially the longer it takes for the mistake to be recognized and addressed. This applies to all aspects of a project, not just the technical pieces. If there are problems with the project, from communication, misunderstanding, deadlines, availability of resources etc... then it would behoove the team to address them sooner, when mistakes are correctable and actionable, rather than after the conclusion of the project. This would be akin to starting off on a cross country road trip and having your check engine light come on 25 miles into the trip, then calling a mechanic at your destination 1,500 miles away to scheudle an appointment to have it looked at when you get there. Only a fool would do that. Sure, you MIGHT make it to your destination in spite of your ignorance but you put the vehicle and your passengers in jeopardy the entire way. If your project's check engine light comes on, take it to a mechanic, figure out what is wrong, and make a plan to fix it now...not when, or if, you get there.