Please login or join to subscribe to this thread
Lessons learned for many orgs have their own templates to brainstorm and gather what went wrong and right so we follow improved steps and design a process for the next time around.This is best done with the team, in a meeting, seeking everyone's input and having a healthy discussion. Obtaining consensus is the best way to obtain one.
I am not sure if there is a "best" process for gathering LL.
With my teams we usually sit together at the end of the gate review and discuss and collect them. At the end of the project we review that we already collected and finalize the LL.
Lessons learned must be a component inside a Knowledge Management environment to be effective. If not, lessons learned will be data instead of information.
Came to basically say what Sergio stated.
- open communication environment
- timeboxed reviews (preferably on a monthly basis like Sprint Reviews)
- Conflict Management
Hello Samer: I try to list bullet points all the way through the project so when we gather as a team at the end of the project, we review the list together and decide what to use in the final document. This simple list has saved many hours for the team - the ideas are in bullet points and then everyone adds to it. Works great for us and helps us not miss something important that would be helpful down the road or for others.
That may vary to project by project, but if it´s a BIG PROJECT, with a lot´s of phases I would prefer to do LL on each gate and a BIG review at end.
As several people have mentioned, don't wait until the end of the project. Capture critical points as you go, and hold LL meetings at the end of each phase. If you wait until the end of the project, most of what you hear will be the negative and maybe some exceptionally positive - not much in between. Organizational memory tends to be better at remembering the negative.
I also try to make sure that most of what I capture in LL is actionable. You may decide to NOT act on it, but if you document LL in a way that identifies an owner and a timeframe to follow up on it, you can end up with more meaningful LL documentation.
It is all about continuous improvement. The key to 'good' lessons learned is implementation. If I had a dollar for every lesson learned log that was never implemented I've come across I would have 100 bucks. There is always tremendous focus on how to capture lessons learned and we use spreadsheets, collaboration tools, knowledge bases and a few others, but if you implement the lesson you have just learned into your processes as soon as you learn it, it's done. I wrote an article about this some time ago but it counts as one of the most expensive phrases on a project - let's just push through, we will circle around and fix it later i.e. we learned our lessons but will wait to implement it until after we are done.
I posted a Wiki for a lessons learned program. Maybe this will help you. https://www.projectmanagement.com/wikis/39...Learned-Program
Please login or join to reply