By Cheryl Toth, MBA bio
What do you call the CEO of three failed start-up companies? Experienced.
Leaders like this are hired time and again because they’ve made mistakes and learned from them. The lessons they take with them to their next role carry a lot of value.
A rite of passage to becoming a great manager is learning to fail in a way that stretches you without breaking you and results in wisdom that improves your resilience and future decision-making. In other words, failure is not necessarily bad. Your ability to grow from the experience, however, depends on your willingness to honestly assess the good, the bad, and the ugly of what went wrong and why.
Creating a written summary of these lessons is an invaluable way to conduct this assessment, as well as to get everyone’s feedback on the table. Even if you don’t refer to the written summary ever again, the process of reflection and documentation will embed at least the high priority learnings into your culture.
Writing the summary
Here are five questions to guide your summary.
1. Describe the project. What did you originally set out to do?
Sometimes a project fails because it veers off course from the original thing you planned to do. That in and of itself can be a lesson learned. Which is why it’s important to document the original project and goals.
Describe a bit more than “Implement a new EHR.” Were there specific goals to achieve? Were you attempting to streamline workflow? Eliminate paperwork? Provide patients with additional payment options? Did you have metrics you wanted to achieve? Answers to questions like these put your lessons learned summary in context.
2. What actually happened and why?
Summarize the major things that happened during the project, and include dates if you can. Was the project a success? Were any major milestones missed? Did the project stay on schedule?
Next, record why these things happened. The “why” is particularly important for understanding how to improve things in the future. Do your best to keep this section objective by focusing on what happened, not the people or personalities that may have impacted things.
Perhaps the project was a smashing success. You launched a patient portal with hardly a hiccough and you’ve found that more patients than expected are using it to register and schedule appointments. Write down things that contributed to why it went so well. Did you have a highly capable staffer lead the project? Did you receive stellar service from your IT consultant? Was the portal something that patients had been requesting, so there was a pent-up market need? Summarizing reasons for success gives you a well of ideas to draw from next time a similar project is not going well.
And when a project does end in disaster, writing down what happened and why is invaluable to debriefing physicians, explaining unexpected expenses, and doing your best to avoid the reasons for failure when planning future projects.
3. What did you learn?
This is the meat in your lessons learned sandwich. Write out what you learned, and ask the team what they learned as well. What worked? What didn’t? What happened that you didn’t expect? What could you have done better?
I recall an 8-physician group that switched its staff model from a per-physician appointment scheduler to a cross trained front desk and appointment services team that supported the entire group. The physicians chose not to pay staff to come in on a few weekends to practice the new systems and conduct role plays. They also didn’t think it was worth the effort to pilot test the changes with one or two physicians before implementing the new system for all eight.
When the new teams and systems were launched for all eight physicians on the same day, it was total chaos: unprepared staff, long patient wait times, and angry physicians. Upon reflection, the physicians agreed they had been pennywise and pound foolish. They also wished they had agreed to a pilot test, as many things happened that no one expected. In the future, they factored in time for trying things small before going wide with big changes.
4. What could you do better next time?
List things that you and the team realize you could have done better, had hindsight been 20/20. Should staff have received more training? Would you have spent more time analyzing current workflow before making decisions about how the process would change?
I find that the answer to this question comes fairly easily after documenting the lessons learned. What’s important is that you write these things down when they are still fresh. Six months after the project is complete, it’s much harder to remember them.
5. Anything else?
Asking this question opens the door for staff to raise issues that may not have otherwise been addressed by the first four questions. You may be surprised at the candor and quality of the conversation that follows.
Share the summary
Once completed, distribute and discuss the lessons learned summary in a monthly physician or partner meeting. A template like this one makes it easy to create a one-page summary. Use bullet points to summarize the responses to each question.
If the project was large or high profile, you might deliver the summary as a PowerPoint presentation, which allows you to include photos and other images to enhance it.
| Editor’s picks: | ||
 Creating a project plan that works |
 5 proven levers for improving your medical practice |
 5 essential steps to successful strategy implementation |
