Making Lessons Learned Searchable by Focusing on Relevance
In a 2012 McKinsey report, The Social Economy , researchers found that knowledge workers spend almost 20% of their workweek searching for and gathering information on how to do their jobs. That’s one full day of work a week dedicated just to looking for information.
Knowledge and information sharing is critical in all industries. The sharing of experiences and best practices help ensure that companies avoid the things that didn’t work and repeat the things that did. These experiences and best practices can come in a variety of forms, like processes, procedures, or policies. However, some of the most valuable information that employee’s use in their day-to-day work comes in the form of other people’s work experience. Employees seek out the knowledge gained from others who’ve done similar work on similar projects, as these important insights have a value that can’t be gained from reading a manual or policy document. Ideally, this experiential knowledge comes from one-on-one interactions, however as workers become more transient and move from company to company, it becomes harder to find the people who have that critical knowledge.
This is where your lessons learned database is of value. Your organization’s lessons learned database serves as a repository of all the good and bad experiences of previous projects, the causes and impacts, and what was done to mitigate problems and enable successes. However, most organizations have a general dissatisfaction with their lessons learned database.
In our previous blog post, we discussed some of the main reasons why many organizations struggle with their lessons learned programs . We described why capturing lessons learned is often a sore spot for organizations. However, there’s a real issue with disseminating lessons learned when they are captured. Even centralized, company-wide lessons learned databases have issues with searchability. In fact, in an experimental study conducted in 2015, where researchers sought to develop an ideal lessons learned database, the resulting prototype still came short for many users on the metric of “system allows quick access to the information and knowledge stored in the company”. So what are the barriers that hold companies back from making easily accessible lessons learned?
How Do People Search for Lessons Learned?
In order to understand why information are so hard to find by most users of lesson learned databases, we first need to understand how people search for information. In general, people tend to search reactively vs. proactively, and use search terms that are relevant to their work.
Based on what they’re working on: People tend to search for information based on the tasks their currently working on, the role they have, or the projects they’re assigned to.
Based on the status of their work: People want the most relevant information based on the current status of their work. This could include, but not limited to, project stage or status.
Based on similarity to their project: When searching, users want to be presented with the information from projects that are the most similar to their own. This generally means the same project type, with the same project scope.
Why Lessons Learned are Hard to Find
So given the typical search criteria used, what are some of the shortcomings of traditional lessons learned databases?
Lessons learned are poorly categorized: Lessons learned categories are typically given overly broad and vague categories. These categories include terms like “Change Management”, “Performance Management”, or “Conflict Resolution”. The problem with these terms is that people don’t proactively search these terms in their day-to-day work. As mentioned above, users tend to search using terms that are relevant to them, like job title or project task.
There’s a glut of information (often outdated): As your organization does more and more projects, your lessons learned database gets increasingly full of data. This makes relevant information even harder to find. If an employee types a search term like “contract management”, they’re likely to get hundreds of lessons learned return back to them. As well, much of this information is no longer relevant.
Inability to search based on project context: Even if an employee had time to read through the massive amount of information presented to them when they search their lessons learned database, it’s hard to know what’s relevant to what you’re working on. For a construction manager working on a high rise project, searching the term “safety” could give her safety lessons learned related to a housing development or road construction project. While these may be useful pieces of information, they don’t give her the information she needs for the work she’s currently doing.
How to Improve Lessons Learned Searchability:
Start Sorting Lessons Learned by Project and Make Projects Searchable:
The first thing people usually do when searching for relevant lessons learned is to look for projects similar to their own. This starts with looking for the same project type, then looking for project scope details that match theirs. Going back to the construction manager example, if they’re working on a high rise project, they likely want to look at lessons learned for other high rise projects, specifically projects in the same location, for the same client, or using the same subcontractors. So your database should allow them to first search for projects based on these parameters. This way users can search for projects similar to theirs and start viewing the lessons learned for those projects.
Categorize lessons learned based on tasks, job titles, delivery teams and project stage: By tagging lessons learned with job, team and project stage related metadata, people working on similar projects and tasks can find relevant data easier. You can keep the broadly defined lessons learned categories like “Conflict resolution” or “Change management”, but what should also be included as metadata is the tasks, teams and positions that were affected by the lesson learned.
Allow advanced filtering based on the above criteria: Once you’ve added metadata to both your projects and lessons learned as per the above 2 points, you’re database should allow users to filter their search results to find information relevant to them.
Allow filtering by date: Information in lessons learned databases can become stale if it’s for projects that were completed years ago. So another filtration criteria to add would be date created/updated, allowing users to filter out any outdated information within the system.
Going the Extra Mile:
Add notifications for your team when relevant lessons learned are added to the database: Instead of a passive lessons learned database, add functions to it that notifies users when information enters the system that is relevant to the projects or topics they are working on.
Ultimately, lessons learned become more searchable when the user has the ability to easily tailor their searches to their specific work context. Even better, lessons learned become more valuable to your team when relevant lessons are proactively and automatically shared with them.
