All the projects experience a length of their execution, favorable or unfavorable situations, a primordial activity of all the work of the work, in which they are identified, these situations and the analysis of what can be learned from them, for this, there is the instrument of the Lessons Learned, these characteristics allow analyzing situations, analyzing their causes, the impact they had on the project and determining what actions were effective to mitigate their effects in the case of threats, and improve in the case of opportunities of our errors, it was observed that it is an element frequently omitted, lost in the day to day of the work teams and the Project managers.
At what point in the project to document the lessons learned, why it will be effective, the identification and documentation of lessons learned will be done continuously, to ensure that information is not forgotten if left to the end, various software development methodologies and management of projects contemplate the lessons learned, such as, for example, software development, which has established the retrospective meeting held at the end of each iteration.
In project management methodologies, such as the PMI, the lessons learned is a point in the phase or project closures, as well as in the scope, cost, quality, time, etc. control cycle. Good method for the treatment of ideas learned in work meetings, is a list of questions like the following:
What project objectives were achieved? (Date, Cost, Quality, etc.).
What worked well in our project?
For each aspect that went well or goal achieved: What is the root cause that triggered this positive result?
Which objectives were not achieved? (Date, Cost, Quality, etc.).
What did not go well in our project?
What unforeseen events or surprises did the team have to handle?
What circumstances were not anticipated?
For each aspect that did not go well: What is the root cause that caused the difficulty?
Just to say some, I would like to share your opinions and recommendations to make a template and automate this process. Saving Changes...
Sort By:
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
LL certainly are important to future initiatives. Documenting LL is an ongoing activity throughout the project. Although many think they will remember key decision points, they will surely be forgotten or lost in transition. For LL to be effective, there needs to be an authoritative, centralized, accessible, and searchable tool for which to include the findings. Each projects LL eventually become part of the organization's knowledge base. Saving Changes...
This is a long running pet peeve of mine. Most companies rarely have a better than 5% good lessons in their repositories as minimal effort is spent in curating and scrubbing them. A couple of key tips I'd offer are:
- Categorize and action them appropriately. Reminders should be treated different than Blockers and those should be treated different than "true" knowledge.
- Bake them into your standards, training materials and policies rather than storing them somewhere and hoping that "if you build it, they will come".
It is good to have a role for this activity. Everyone should know they have to contribute to LL through the project. Someone has to be saddled with 'collecting it from 'everyone' ' and documenting it.
Then for the organisation, someone has to collate and sort, afterwards archive - there can be same LL from more than one projects. Saving Changes...
