Join Haydn Thomas for an in-depth discussion in this video Capturing lessons learned, part of Business Analysis Foundations.
- The popular quote "Fool me once, shame on you. "Fool me twice, shame on me," truly applies to projects. However, the business world in Western society does not have a good track record. We are often fooled twice, three times, or more. The pervasive and consistent rate of project failures is a testimony to that fact. The best way we can all stop getting fooled is to do a better job at capturing and sharing lessons learned. To do this effectively, there are a few best practices I'd like to share with you.
First, this is not an activity for the end of your project. Lessons learned should be captured in a central place from day one of your involvement in the project. The lessons should be categorized, and, if appropriate, summarized and filed at the end of your project after consulting with your colleagues and clients to make sure you have a complete account of things to avoid and things you want to repeat in the future. Lessons learned shouldn't be just bad stuff.
Second, make sure you use common terminology. Capturing, categorizing, and filing lessons learned does little good if the information you are capturing cannot be located and extracted easily. Think about how you would try to locate the lessons learned information in one year's time. Provide an index to help you, as much as more likely to truly have lessons learned, versus lessons written down and lost forever. Third, it's ok to capture your own opinions and impressions.
The most likely candidate for a person who will reference your lessons learned is you. Therefore, it's fine to include your own perspectives and opinions for the lessons you learned and don't want to forget. However, when doing so, you may want to capture if others have dissenting opinions, that way, if someone other than you reference the lessons, they can chat with you and your dissenting colleagues to form their own opinion, and set their own direction accordingly. Fourth, ensure you talk about events and outcomes, not people and roles.
This ensures you can be candid and frank about the directions taken, the results they produced, and what might have been done differently. Fifth, include the signal for red alert in your lessons learned information. When did you realize that you were not in an ideal situation? What outcome gave you the impression that you needed to do something differently? As not every lesson learned will yield the ultimate correct decision for the future, any signal that you can capture that indicates a decision or direction might need to be revisited is valuable.
Explain your rationale, and what you saw happening that indicated you had gone astray. And lastly, make sure each lesson learned include the stage of the project where it should be applied in the future, and specifically what business area or project team was adversely, or positively, impacted by the event. Doing this helps provide focus for future, and can help indicate tasks that need to be added or changed in future projects. Lessons learned can be, simply, lessons written down and forgotten if you're not captured with a small bit of rigor and an eye to the future reader of each lesson.
Gathering lessons learned throughout the project lifecycle ensures you're capturing elements when they happen. And as people in projects often have short-term amnesia, follow these tips and you and your organization might just avoid being fooled twice.
Discover where business analysis lives in the project life cycle, how to initiate a project, the best way to gather requirements, and smart strategies to monitor results and test outcomes.
Lynda.com is a PMI Registered Education Provider. This course qualifies for professional development units (PDUs). To view the activity and PDU details for this course, click here.
The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.
- Understanding what business analysts do
- Defining business opportunities and objectives
- Identifying stakeholders
- Gathering requirements through observation and brainstorming
- Validating requirements
- Developing project acceptance criteria
- Implementing, testing, and closing your project<br><br>
- The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.