Pipeline Stories: Lessons Learned From Lessons Learned

In the fast-paced world of drug discovery, implementing a Lessons Learned program can be challenging at the best of times. At a recent Portfolio and Project Manager’s Meetup, I had the chance to talk with some folks from a local biotech company that were in the process of implementing just such a program.

There are a number of common refrains that Project Managers typically hear when attempting to implement a Lessons Learned program:

• We’re done with that, let’s move on. Nine out of every 10 programs fail, so when someone suggests that you stop and take the time to look at the gory details behind a failure (that in truth, they don’t want to be associated with), it can be a hard sell. But the problem is the misperception that Lessons Learned is all about doing a root cause analysis of a failure, instead of making sure that we record what we learned (good or bad) from this project in a manner that we can easily re-use in future projects. That really cool synthetic route that improves your binding affinity which was recorded in an ELN that no one ever looked at again. That trick to getting the cell-based assay to work properly, just walked out the door in the head of the lab tech who’s now working for your competitor. Those scenarios happen every day, and a Lessons Learned programme can help create an institutional memory in ways that simply recording it in an ELN can’t.
• My plate is full, do we really need to do this now? At the end of a project, people are moving on to the next big thing. They’re getting up to speed on their new projects, or the next set of tasks they’ve been assigned, and taking several days to a week to do a Lessons Learned exercise can seem like something that has little direct benefit to them at a time when they need to focus on their next assignment.

So, how do we solve these challenges? How can we implement a programme in ways that benefit both the organisation as a whole and individual participants? Keeping in mind that not every problem has a technical solution, in this particular case it’s often better to think of any solution as a three-legged stool consisting of people, process and technology. So let’s take a look at each leg in-turn to see how we might implement a Lessons Learned programme.

Process
The standard approach for performing a Lessons Learned Exercise is to wait until the end of the project, bringing the team together for several days to a week, go over each of the stages of the project, review the tasks, risks and issues, and put together a document that accurately captures all of that. But the problem with this approach is that often the lessons that you learned years ago during the Target Validation or Lead Optimisation stages of the project are long forgotten by the time you decide to perform the Lessons Learned Exercise. A better approach is to perform smaller, more tightly focused exercises at the completion of each stage. Since it’s shorter in duration, you’re often not faced with the same resistance that you might otherwise encounter.

Break the meetings into smaller more focused sessions with team members from the same group. Have a biology meeting, a chemistry meeting, etc.

Borrowing from the PMIs guidelines for lessons learned (and the CDC’s PMG guidelines as well) here are a few general questions that facilitators can use to get things kicked off, and some more focused industry-specific questions as well:

• What went right?
• What went wrong?
• What needs to be improved?
• Were there any issues that occurred during this phase (eg. Target Validation), how did we solve them, what did we learn, how can we apply this learning to other projects in the future?
• Were there any risks that we identified and dealt with, or failed to deal with properly?
• Were there any handoffs between groups where data had to “munged” prior to handoff? What can we do to make that smoother?
• Were there any issues with vendors or instruments that affected or might have affected our results? If so, how did we compensate for this? What should we do about this in the future?
• Were there any automation-related issues and how were they handled?

People
To counter the negative bias that can be associated with “raking up the past”, it’s important to emphasize that the goal is to record the successes as well as the failure. How can we make sure that the next time that the same situation arises, that your colleague will be able to repeat the success, or avoid the failure?

In some companies, Lessons Learned are part of an overall program of continuous improvement with a built-in reward mechanism. Many years ago while working in Royal Dutch Shell’s Knowledge Management Systems group, one of our tasks was to implement a system that tracked how often a lesson was re-used, and to reward the person who created the lesson. The system tracked cost-savings for the company as well. Each time the lesson was applied, a cost-savings was realised, and the employee was rewarded. This is one of the few applications I’ve worked on where the value of the application was made obvious by the application itself.

That approach worked well for a large multinational company, but might not work well for a single site. My point is though, it’s important to understand and formulate culturally appropriate reward mechanisms whether it’s information that goes into your personnel file as part of your annual review, or points which can be redeemed at the company store. That reward mechanism helps ensure that employees are constantly looking for areas of improvement within the company.

Technology
How does Pipeline help you implement a Lessons Learned program? To begin with, we give you tools for capturing the lesson.

You can create a lesson at any point in the discovery process and add them to your library. The library gives you a cross-cutting view of the lessons learned from all of your projects. You can add documents to your lesson, journal articles and even PubMed searches, to help insure that your lesson has all the supporting information it needs.

To insure that your lesson is applied in other projects, we use the metadata around the lesson to help bring that lesson to the surface just when you need it. You can think of it as Match.com for lessons learned.

For example, suppose your lesson had to do with a neat trick for improving binding affinity for targets with a very specific domain. The metadata for the lesson can include domain information. Whenever you tackle a new project with the same domain, the lesson appears as a suggestion. To view the lessons that match the characteristics of your project simply open your project, and select Lessons Learned from the menu.

This helps you realise the true value of your lesson by applying it in multiple situations. It means that even with personnel changes, the institutional knowledge of your organisation doesn’t walk out the door. It’s used and re-used by the right people at the right time.

References

• Strategies for Learning from Failure – Harvard Business Review
• Facilitating effective project meetings – Project Management Institute
• Is Yours a Learning Organization? – Harvard Business Review
• Lessons Learned: Taking It To The Next Level – Project Management Institute
• Lessons Learned – Centers for Disease Control

Read more of the Pipeline Stories Series

---

To learn more about how we can help your organisation, contact us.