Lessons Learned databases tend to be cumbersome, messy, and are difficult to use effectively. Likewise, the practice of capturing Lessons Learned and phrasing them so that they are useful in the databases is tedious and seems like a waste of time. Instead, get in the habit of updating, real-time, a checklist of “bite-me” notes directly into your product development roadmap.
The practice of keeping a Lessons Learned database or list of problems encountered before, to be avoided or prevented in the future, has come and gone many times over that last two or three decades among product development practitioners. It’s a great concept to capture lessons from one project and preserve them for future projects, to avoid repeating mistakes or problems.
Unfortunately, presenting those lessons in a format and forum that truly makes them useful is a real challenge. After more than a couple of dozen lessons have been recorded, it is no longer practical to expect a project leader and team to read and remember those lessons while starting or executing a new project.
We have used databases and key-word-searchable contexts, but unless we intuitively know what to search for, it isn’t helpful. We could spend hours searching the database and still repeat a past mistake because we didn’t think to search for the right keyword. It’s just not helpful to need to anticipate something in order to find the record that tells us to anticipate it.
The end result is that every few years, we get a great idea to develop a Lessons Learned system or record, we begin to populate it and try to use it, but eventually we give up, as it becomes a time-wasting exercise in futility. Does this sound familiar?
I do have a solution to recommend that is worth trying. My colleagues and I have developed a system for capturing lessons and preserving them in a practical way for future projects. Likewise, it is easy and practical to review and address those lessons without degenerating into red-tape quagmires of waste.
There are three basic problems for any Lessons Learned system. They are as follows.
1. Capturing the lessons
2. Presenting the lessons in a useful format
3. Inspiring the review and consideration of those lessons
Let me describe a solution that addresses each of these, in order. Bear in mind, it will require some change of habit and some discipline to incorporate the solution I recommend, but I can say with confidence that it is feasible, and it does work.
1. Capturing lessons needs to be done when the lessons are discovered. The more real-time we can make the practice, the more effective and less wasteful it becomes. If we wait until the end of a phase of a project, or the end of a project and then try to resurrect lessons from memory we inevitably induce a wasteful practice.
Retrospective lessons reviews have 4 inherent problems. First, they tend to hold an entire room full of cross-functional participants hostage for several hours of more-or-less non-productive time. Second, they become a brainstorm of thoughts and memories and unless we have a strict system of scoring the risk and impact value of each idea tossed out, we tend to generate an unnecessary multitude of lessons. If we do have a tool or system to screen lessons, then we must spend time in the meeting using the tool on the long list, making the meeting even longer.
Third, reflection, though it tends to be more objective and less emotional, is not always accurate. It becomes easier to argue the impact or importance of some lessons when the pain is a distant memory. Also, there is always the possibility that an important lesson will be forgotten. Sometimes things are not forgotten, but because of embarrassment or political correctness, they are re-described in a way that makes them much less impactful.
Fourth, and finally, the lag between the error and the record, leaves a window of opportunity for other projects to repeat the same mistake whereas a real-time distribution of lessons might save another project from the same error. Suppose that the lesson happens to be that a new supplier does not actually have the process capability that they advertise. Another project, running at the same time, might be planning to utilize that same supplier. Wouldn’t it be important to save the second project from discovering what the first project team already has?
It is just better to capture lessons immediately, when they are learned and add them to the list of things a project team should consider for the next project, or for projects that are already underway. It wastes less time and energy, and the information produced is more useful and timely.
2. When we capture the lessons, they must be presented in a form that is useful for other teams. Simply recording events and discoveries in a database fails to satisfy this need. Here is a method that my colleagues and I have found to be functional, and simple.
Phrase lessons in terms of actionable recommendations or tasks. Make them generic for all projects, not specific to projects or entities. Using the example above of new suppliers meeting capability, we would create an actionable phrase something like this. “Verify process capabilities of new suppliers, don’t assume or accept.” We might even add, “Update/Correct supplier capability database.”
Please note that we would not phrase our lessons as, “Supplier JXTY said their capability was 1.33 but we found it to be 0.96 and we spent 5 weeks trying to reconcile their process capability with our design.” While it is a reasonable statement about the lesson, it is neither actionable, nor does it specifically instruct the next team to avoid the same lesson. After all, what if the lesson applies to other suppliers, not just JXTY?
There are some very good reasons for phrasing our lesson as an actionable recommendation or task and in broad or generic terms. What we are looking for is an action that prevents the lesson from being re-learned in the near or distant future, with any similar circumstance.
The more broad or generic the action, the fewer times we must create a new lesson or task. If we record that Supplier JXTY overestimates their process capability, then we could end up with dozens of records for dozens of suppliers over several years. How did we find out about the other suppliers, the same way? No help to ourselves there.
Not only do we keep our list of lessons short, it enables a presentation format that is eminently useful. We are going to add our actionable statements about lessons to our product development checklist, carefully. Don’t panic! We are not going to take an already cumbersome checklist and make it impossible.
Our lessons learned actions become a list of considerations or “Bite-me’s” that accompany our design checklist. They need to be different, an addendum, because we are going to enforce them with a different set of rules (see part 3 below).
Using the same supplier capability example, find the portions of your gated product development process, or your product development checklist where supplier selection or supplier discussions take place. Add the actionable statement to that section, not as a must-do checklist task, but as a “hey give some thought to whether this could be a problem for your project too” item.
If your organization personality is professionally stern or politically correct, call them project “considerations.” If your organization’s personality is more fun-loving call them “Bite-me’s” or “Gremlin Preventers” or “Murphies.” Call them whatever communicates the intent, which is that these actions are listed to help project teams anticipate and prevent problems.
I find it very helpful to subdivide the list of considerations into specific fields of interest or application. For example, there are those, like supplier capability, that are general design project concerns, but others might be specific to mechanical design, electronic design, software/firmware design, or to specific tools or analytical methods. A handful of short lists is much more manageable than a single enormous list. Likewise, a whole slew of miniscule lists make things difficult to find or categorize without repeating some.
In the context of a list of considerations or “Bite-me’s” I hope you can see why we phrase our lessons as actions, and generically. If you have a database of lessons learned already, then go ahead and continue to put specific lessons in that database. Sometimes having that historical example is very helpful to the project lead trying to understand or decide if a consideration might be a genuine problem and if the action should be addressed. The benefit is that now you have a catch phrase to which to associate the lesson so it can be found and reviewed easily.
The list of considerations or “Bite-me’s” must be managed in such a way that it is relatively easy to compare new lessons with the existing list and see if such a thing is already addressed. If the list must be updated, it should be quick and easy to do so, with a minimum of delay and red tape. We need to keep our lists from growing out of control or from losing context, but if we make it too difficult, we can’t satisfy the objective of real-time lessons capture.
3. Now that we are capturing our lessons real-time, and incorporating them as actionable considerations in our design project guide, we must encourage our teams to review and act appropriately upon those lessons. We do this with our existing review and project management practices.
Because it is a relatively common practice today, I’ll assume a segmented and gated design process for the sake of discussion. At gate reviews and design reviews, get in the habit of asking design teams which considerations they addressed, and most importantly, which considerations in the next part of the design process they feel are worth addressing.
Fundamentally, it is not helpful to ask if a team addressed considerations in the past. It’s past, and too late to prevent new lessons, or repeat lessons. We can however ask if a team followed through on its commitments or plans.
The point is prevention, which requires a view into the future. Establish an expectation that your design teams identify the considerations that are likely to be valid for their projects and put actions into their plan to address them. Plans are value-added; corrections are waste.
As you establish this practice, be diligent about maintaining the vision and purpose. We are not trying to over-burden our projects with unnecessary tasks. We simply want our teams to consider and appropriately address the lessons of past projects. For example, if a team is only using familiar and well-established suppliers, they should not act on the consideration we have been using as an example. Verifying supplier capability for a supplier for which substantial data already exists is a waste of time and energy.
Set the expectations of reviewing and communicating plans surrounding considerations and “Bite-me’s” at your regular review periods. Design reviews and gate reviews are obvious opportunities. They must be timely enough to allow for planning and not so frequent that they become a burden or waste activity themselves.
There we have it: three fundamental challenges or problems with Lessons Learned systems, addressed in simple and pragmatic ways. I made some assumptions about regular reviews, and design guides, and design processes for the sake of describing the solution I recommend. Your own organization’s elements may be very different.
If you don’t use a structured design process or design checklists for example, it might be more difficult to visualize how to incorporate the suggested elements. Take a step away from your daily challenges for a few minutes and think it over. Regardless of your organization’s current methods, the answer may not be to incorporate precisely what I have suggested. The best answer will inevitably be to leverage the methods you do have to incorporate the fundamentals of the solution described.
The fundamental elements that will make your organization able to utilize lessons learned are as follows, to summarize the discussion above.
1. Capture lessons and update lists real-time
2. Phrase lessons in terms of generic, actionable recommendations or tasks
3. Make the list of considerations (lessons rephrased as tasks) part of whatever information your teams use to guide projects
4. Proactively encourage a review of the lists and incorporation of appropriate plans at your regular project reviews
It’s that simple. If it sounds too simple, you just haven’t tried it yet. Yes, the solution itself is simple, but making the behavioral change to incorporate it and make it work requires some work, just like any behavioral change. It will take some work to establish a habit of phrasing lessons correctly, updating lists real-time, and sticking to plans to prevent problems.
Lessons Learned has been an idea many of us have chased for a very long time. Like any reasonable solution, the one presented above is simple. Simple is good. Take some time this week and examine your own Lessons Learned system and practice. If it could be improved or simplified by some of the suggestions above, then by all means give it a try. If you haven’t got a working Lessons Learned system, try the one above. It can be a real project saver.
Stay wise, friends.