Ask different project managers and get different reasons why project management and the PMO is important. For me, communication provides PM’s greatest value, and building a lessons learned file is one of the most valuable (and overlooked) communications practices. Project management has been around for a very long time and the Pyramids of Egypt (hundreds built and 80 still standing after nearly 5,000 years), the even larger pyramids of Mexico and South America, the Roman baths (thousands were built around the world), and the endless dams and water control systems of ancient China… were built long before modern project management was developed. Yet, we’re still figuring out how these incredibly well known projects were performed. What about failed projects? Consider Percy Bysshe Shelley’s poem, “Ozymandias.” The stumps of a statue’s legs, abandoned in a forgotten desert, once pointed towards a great city but now faces only desolation. On the base is inscribed, “Look on my works, ye mighty, and despair!” That’s not teenage irony, that’s a PM’s best argument for building a lessons learned file. Empires collapse,  leaders fall and mighty civilizations can disappear without a trace. Success leaves artifacts behind, but the  lessons of failure are too often buried with the failed project. Today’s blog is about the lessons learned file and how it can help us learn from the past.

When a project works out, we have an incentive to leave behind critical information so that our success can be replicated. Even so, there are new projects waiting and we want to move on to these projects rather than write up materials on a closed project. When the project stalls or fails… well, we think we’ll eventually get around to writing everything up, but we don’t.  The reality is that everything you add to the lessons learned file is a force multiplier. Do something very clever on a project and the project gets better, but document that clever idea and you can benefit many projects. A very large part of this problem is that human memory is very tricky, and unreliable. When we’re in the middle of a huge problem, it may look like there is no solution. But we started to think about the problem weeks (or months) ago, we may have worked on similar projects in the past, and perhaps developed a partial solution. As all of these bits and pieces move around in our heads, the “AH-HA moment” may sneak up on us as all the information in the back of our heads suddenly slides into place. A few weeks or months later, when it’s time to write up lessons learned, it now seems that the idea was “obvious” and it never occurs to you to document it.

OK, we all agree that sharing information is important, but how important? Let’s take an extreme example. Every day, people die. But we are often affected most when it’s children who die. Years ago, a child diagnosed with Leukemia (the most common childhood cancer) was not expected to survive to adulthood.  In the early 70’s the 5-year survival rate rate was 68%, but for some forms of Leukemia the survival rate was in the low 30’s. Today, the 5-year survival rate rate has risen to 90%. Of course the diagnostic process has improved and treatments are more effective, but adult recovery rates are only 66%. At a conference, I recently met a Pediatric Oncologist who offered an explanation. He told me that his profession had undergone a revolution… doctors were talking to each other. If you know anything about medicine, that seems like a strange comment. Perhaps more than any other profession, doctors have conferences, they write articles for journals, they work in teams, etc. They talk a lot! But this new revolution was driven by mothers who pressured  doctors to talk to each other to get information on new drugs, to check with peers about using a combination of drugs, or deal  with children with unique issues. Normally information is provided at a yearly conference or through reports in journals that take years to research and write; now doctors were talking to each other and having video conferences about difficult cases, greatly speeding up information exchange. They were building and sharing lesson learned files. Treatments improved, lives were saved.

Most of us work in industries and professions where the sharing of information within a group is inconsistent, sharing throughout the entire firm is unusual, and sharing between peer firms is very rare. Yes, some groups and organization do share data, but for the vast majority we think of the formal sharing of information as an optional activity rather than a core function. It’s not part of our DNA and we don’t  know how to move best practices beyond the PMO. Because every PMO is different finding the right way to deal with lessons learned will also be different. However, here are some recommendations…

Involve The Team: Some PM’s believe that the best way to build a lessons learned file is to do it themselves, since they have the best training to identify and document processes. PM’s should develop many of the materials, especially detailed documentation of technical processes, but the rest of the team needs to participate as well, preferably creating documentation as part of their personal development.

Debrief: The best way to identify key learning’s is to follow the military’s example and debrief. At the end of the project, pull the project team together to develop 2-3 key points on what happened, what went right and what went wrong. You will often find that rest of the team has a different idea on each of these subjects. That’s not too surprising when you consider the range of skills and background on the team. Some questions to ask:

1. What did you learn: This may help you to “on-board” future teams.
2. What was your biggest challenge: Look for team patterns for this project, vs. other projects.
3. What went wrong/right: Here’s your chance to fix problems and replicate best practices.

Research Your Results: What appears to be a best practice may be a misinterpretation, and a real best practice can be misapplied. Before you do a full write up on lessons learned, test the idea  using the TREZ methodology. This was developed in Russia during World War II to accelerate the speed of innovation in engineering.  One TREZ concept is that most solutions already exist. Check Google and other resources to see if anyone else has developed a similar solution. Just because no one else is talking about your proposed best practice, doesn’t mean that it’s not a best practice. But it anyone else is discussing it, you may be able to pick up bits and pieces that someone else knows… add it to what you know… and end up months or years ahead. Just like the pediatric oncologists.

Update Old Beliefs: Your new best practice may affect previous best practices. Take some time to verify if previous best practices are no longer true or at least not entire true. If you need to, update or eliminate some old documents in the lessons learned file.

Publish: Go beyond the basic documentation. Write up an article or a blog. Find if your firm has a newsletter or website for internal information. Go to Linked In and publish an article for one of the GROUPS or go to ANSWERS and see if you can get some external feedback on your ideas. Of course, any time you go outside of your organization make sure that you get corporate approval (check with Marketing, or HR or other groups). Also, some firms may have confidential data they don’t want released and you need to understand rules. You don’t want to get your team excited about a soon to be released article on your project, that gets canceled by the firm at the last minute!

Train: Are you sharing your lessons learned file with you training department? Training may have courses that might incorporate some of your information, specific information and PMO functions might be worthy of a training class and the process of collecting and refining best practices might make a good class.

The power of a good lessons learned file is enormous! The more documentation you have on best (and worst!) practices, the more effective your projects will be. Of course, if you have a really good lessons learned file you may be able to completely avoid projects that will never come to completion, or never produce the desired effects. The lessons learned file is a force multiplier and take hard-won  knowledge from a single project and expands it across many projects. Put the time and effort into a good lessons learned process and your entire firm will benefit. And that’s my Niccolls worth for today!