Give New Life To Old Lessons

Perhaps the best idea that is most frequently abandoned across almost every industry is that of capturing lessons for posterity and for sharing to other teams and people, and also using those captured lessons to effectively educate or successfully learn from others’ mistakes.

Perhaps the best idea that is most frequently abandoned across almost every industry is that of capturing lessons for posterity and for sharing to other teams and people, and also using those captured lessons to effectively educate or successfully learn from others’ mistakes. I imagine that each reader has embarked upon this quest at least once, and most have abandoned it as well.

Making use of “lessons learned” is difficult. There are so many challenges to overcome, most of which are either systemic or behavioral, that it often seems impossible. As soon as we overcome one challenge, we face another. It’s daunting.

There is no one successful recipe for capturing and using lessons-learned. I believe the reason for that is because there are as many expectations, needs, methods, and behaviors as there are organizations. One recipe can’t possibly satisfy such a diverse audience.

There may not be a recipe, but there are some fundamental ingredients that go into a successful system and method. Let’s discuss those. 

Of course, this topic comes to my mind for this week’s post because I’m currently engaged with a group that is constructing a lessons-learned system. I’ll describe what we are going through and our thought process, not so you can make the same decisions (these folks’ solution is not going to be right for most other groups), but by way of example of the thought process for developing the right system for your own organization.

This organization is a small group of people with a highly collaborative mind-set, but with a mode of operations that has each team leader working independently to lead his or her own team to complete a project. What’s interesting is that the teams remain consistent over the course of several years, but the teams rotate programs. 

In a five-year rotation each team will generally touch each of five different programs. After five years, the leaders and team members typically graduate to new responsibilities and an incoming team might be brand new. Of course, no human system is ever quite so consistent, but that roughly describes the general plan.

It’s a different program management plan than most organizations, but the challenges of developing a solid lessons-learned system and method are still the same.

For many years, leaders of teams further down the path than incoming teams have collaborated to pass on ideas and best practices and to mentor others. It’s worked effectively for quite some time, but now the organization recognizes that technology could easily expedite the exchange of information and also make the practices and ideas of many leaders more readily available.

For example, one leader needs to arrange a visit with another business in the public market. He calls the leader responsible for the program in the previous year and asks for some guidance. In particular, names and phone numbers for contacts within the organization, lessons about planning the visit for the whole team, safety or communication concerns, and information to investigate or request are considerations of particular interest.

Collaborating when you don’t sit in the same room with someone is generally a waiting game. Leave messages, wait for responses, miss phone calls, look for e-mails, return missed calls, etc. until you finally get all the information you need. 

What if you could just find the information yourself in a network database? What if you could find, not just the previous program leaders’ information and ideas, but also his predecessors ideas all in the same place? This is what this particular organization is after.

And that brings us to the first consideration or ingredient in our lessons-learned solution. First we must make our best effort to identify what information is useful and to whom. I say this is the first consideration because these two decisions will affect most or all of the others. 

The users of the lessons-learned system and the information to be organized in the lessons-learned system will dictate most of the design of a solution. Inevitably, our best effort to brainstorm what information will be useful will be flawed, but it will also be mostly right. Start with your best guess and then accept that you will adjust it as you start using the system. Focus on information that you know will absolutely be useful.

The next element to address is how your group should access the information and where it will be kept. For the group with which I’m engaged, it’s a simple plan. We will use a secured Web page(s) and will roughly organize the page(s) by program. Inside each program folder will be other folders for each basic type of information. For example, contacts, best practices, and mistakes or challenges solved are some of the general categories.

Now it becomes important to determine specifically how information will be organized and formatted. Standardization is critical for any system, regardless of its design. The reason is that, ultimately, the system is a communication system. If your users can’t quickly and effectively create useful information or find useful information, your system will fail.

The design intent around organization and format must be to optimize efficiency and ease of use. If it becomes a chore to use, or if the information can’t be found, it won’t be used. Standardization is a necessary tool because when every folder is organized the same way, and all the information is formatted consistently, it becomes quick and easy to create and to find useful information.

The format that my engaged organization is developing is a simple Who, What, Where, Why, How format. The priority order is a topic of discussion, but not of particular import except that a change of mind later would require re-formatting.

Who would find the information useful helps make sure the lesson ends up in the right organizational place, “What” concisely describes the lesson or the information. Where and when the information comes into play are turning out to be very useful items demanding a standardized list of answers because they are useful search keywords. Certain information is important at specific stages of the program. Searching on that stage’s keyword brings relevant lessons to the fore.

Why the lesson is important and how to apply it is proving to be a useful line item in the lessons’ format. It requires the creator to explain things just enough that someone can effectively understand the intent and the vision of the creator. Without those answers, sometimes lesson descriptions lack context to make sense.

Some standard data management rules also should be applied. Try, as much as practicable, not to replicate information. The biggest concern is placing the same lesson in multiple locations. If that lesson receives edits or comments or addendums in the future, there’s no good way to make those changes to every copy. It’s better to reference lessons than to copy lessons. 

Likewise, creators should look for an existing piece of information that is similar or identical to the one he or she intends to create, before creating a new one. It is better to make an edit or an addendum to an existing lesson than it is to create a new one. The reason is that while we aspire to pass on as much knowledge as we can, if we clutter the system, we fail to use it and fail to pass anything on. Less is more.

That brings us to the final elements or ingredients to discuss. We must establish our habits for using the system. There are three main categories that we will all need to address regardless of our design. We must build a habit of putting useful lessons into the system, we must manage or maintain the information in the system, and we must access the system to learn from it.

The behavioral element is where most lessons-learned endeavors fall apart. If the design and development of the system did not enable ease of use and a high degree of efficiency, the behavioral part of the equation will break down. If it’s not easy, it won’t happen. That needs to be the motto of the design of the system, and also the establishment of the behaviors.

First we must populate the system. The team with which I’m engaged put forth a great plan to get the system started. Each program leader developed a list of information that they think their follower would like to have or should have available. At the same time, each program leader created a list of information that they already know they want to be able to quickly and easily find. The two lists together make up the action items for each program team lead.

The list each program team lead created for his or her follower combined with the list each following program team lead created is the total list of information each team lead is tasked with creating and installing in the system. It will take some time for each task list to get satisfied, but a weekly quota or a deadline makes it remain on the priority radar.

The best advice I have for the organization in terms of developing habits for using the information they are creating is to follow a simple rule. Before contacting a predecessor for information or advice, the user must first consult the lessons-learned database. This will drive practice and proficiency with the database, and it will also drive an appreciation for effectively communicating ideas in writing inside the database.

Similarly, I advise that if a user of the lessons-learned information calls a creator of a piece of information for more clarity or more advice two things should happen. First, we should cheer that the database is working. It means that people are using it, finding relevant information, and are connecting with people that have the knowledge to pass on. This is good!

Second, we should follow a rule that insists the creator of the information must immediately revisit the information in question and try to improve the clarity or content of the information, based on the questions it generated. This helps ensure that the information remains useful.

Finally, we must establish habits for maintaining the information in the database. It is best to maintain it real-time, not like letting our bedrooms get messy for a long time and then spending a weekend cleaning up. While our system is messy, it’s not useful, so we must keep it up all the time.

If a user finds a piece of information that is no longer relevant or is simply not helpful, it should be addressed immediately. It should be sent to archive, deleted, or routed to the creator to be fixed. Each organization will need to decide for itself the best process for doing this. 

Lessons that lead to process changes or work instructions should be addressed as soon as the improvement is identified. There is no sense in waiting to improve a process and losing productivity or creating more errors while you do. These findings should funnel directly to process improvement pipelines, not into lessons-learned databases where they won’t be immediately turned into process improvements.

For the organization I’m working with currently, they will simply delete something that isn’t relevant and will send it back to the creator if it is just not clear, no approval mechanism will be installed. This organization’s personality dictates that the system will stay clean best this way and the risk of losing critical information is small.

That briefly covers the critical elements of a lessons-learned system and method. Let’s take a few lines to list them for quick reference.

  • Identify the users of your system
  • Identify what information you want in your system
  • Determine how users will access the system
  • Determine how to organize the information
  • Determine how to format the information
  • Establish rules and habits for creating information
  • Establish rules and habits for using information
  • Establish rules and habits for keeping the system clean

It seems like a simple list of elements, but that doesn’t mean that putting them all together in an efficient and effective system is easy. Designing the system to be easy to use requires some careful planning and troubleshooting. Establishing the habits to use and maintain the system requires some understanding of behavior and some leadership. The underlying focus must be on simplicity – making it easy.

The organization with which I’m engaged does not want to operate according to strict processes or formalized work instructions. However, it does want to be able to pick and choose among opinions of best practice or from ideas to improve a team’s ability to meet customer needs. It wants to be able to quickly access useful information without waiting for a busy person to respond.

Each organization will have different needs and different expectations. For that reason, each organization will need to develop a lessons-learned system that suits its needs and a method that fits its culture. One size does not fit most for lessons-learned solutions. 

Review the ideas and the list above. Look at your own system. If it isn’t functioning well, which element is the source of the breakdown? Identify it and fix it. If you aren’t using a lessons-learned system and method, consider what it would take to install an effective one. The key is keeping it simple, easy to use, and free of clutter. It can be done. It just takes some careful thought and planning, and some leadership to get into the correct habits.

Stay wise, friends.

If you like what you just read, find more of Alan’s thoughts at

More in Industry 4.0