Without exception, in every organisation I have ever worked with, I have always heard it expressed that:
a) “We don’t do Lessons Learned very well,” and
b) “If only we could do it better, our project delivery would be more effective.”
It doesn’t matter whether you speak to project managers, PMO leaders or senior managers, the view is always the same. As a result, I have often been dragged into various initiatives to improve matters. My involvement has often been reluctant, as it is my view – which I have never hidden – that such attempts are doomed to failure! Why is this?
What most organisations regard as “doing Lessons Learned” is to build some sort of database in which the lessons are logged, tagged, categorised and organised. It might be a full relational database, an Excel spreadsheet, or a Wiki. But the result is the same: a “write-only” repository which starts off with good intentions, grows a bit, but is never consulted, falls into disuse, and eventually is abandoned.
I recently came across an organisation whose PMO function has a target of how many entries they can record in their lessons learned database per month. There is no measure of the quality of the entries, nor of their subsequent use or value to future projects. The result, of course, is to guarantee that the database continues to grow… continues to consume effort… and continues to provide zero value to the business.
And yet I also strongly believe that evaluating Lessons Learned is something that every project should do, because it contributes strongly to any organisation’s culture and future delivery capability. It isn’t the learning that I’m opposed to; it is the sheer wasted effort on what is often called (wrongly) a “knowledge database”.
Why we need to Learn from Experience
“Learning from Experience” (LfE) is the new and trendy name for “Lessons Learned”. It is a change that I definitely agree with, for two reasons:
- It reflects what we are actually trying to do. To learn from experience.
- It avoids the tedious and absurd debates over whether it should be “Lessons Learned” or “Lessons Learnt”!
The end-of-project LfE workshop presents the following opportunities:
- To share experience, learn from what happened, and make improvements for future projects
- To air any grievances or misunderstandings, and by doing so “wipe the slate clean” for the next encounter
- To make recommendations for improvements to processes, systems and working methods
- Team-building for future endeavours
Writing down the output and putting it into a (cough!) knowledge database is the usual outcome from such a workshop, but it isn’t where the benefit lies. The organisation’s real learning is in the heads of the individuals. Most of the same people will (hopefully) be working on the next project together or apart, and it is what they learn as individuals that contributes to organisational culture and improvement.
Unfortunately individual experience and learning is a rather intangible output, and certainly can’t be measured as a key performance indicator, but nevertheless it is at least 95% of the reason for holding an LfE workshop.
Actually there is a pragmatic way to record findings that apply to other projects, not involving a database. Do you use a risk register? Do you have a risk register template? Does it come pre-populated with common risks? If the answer to all of these questions is “yes”, then that is the place to put any relevant LfE findings. It pretty much guarantees that they will be in-the-face of the next project, without them having to interrogate a database. (And if the answer to any of the questions is “no”, my next question would be “why not?”)
How to hold a Learning from Experience Workshop
Here are some hints and tips for holding an LfE workshop, gained from my experience of participating in and hosting many such events.
- Hold it as early as possible in the project closure phase. Team members can start to escape quite quickly, and as soon as they are onto the next project they won’t want to give you any time.
- Make it clear to team members that their full participation is expected. No excuses.
- Allow plenty of time. At least half a day, possibly a full day.
- Hold it face-to-face and off-site, if possible. That way you get full engagement and fewer distractions.
- Use a neutral facilitator. The project manager is likely to be at the centre of the discussions, and is probably the least desirable person to have running the meeting. Invite another project manager (you can return the favour some time), a PMO member, or an external specialist. Commercial break: This is a service I provide. Can I help?
- If you have external vendors, invite them to participate, and ensure right from the start of the project that they understand that participation is expected – so that they don’t try to charge you for this variation to the contract. In any case, if they are expecting to work with you again, they should see the mutual benefit. But split the workshop into two sessions, part with and part without the vendors, so that your internal team can have a good moan!
- Instruct participants to prepare for the meeting in advance, by thinking about and writing down (a) what went well, (b) what went badly, (c) what to do differently next time.
- Invite the Project Owner to set the scene at the start, but then make it clear that they should make their excuses and leave. The discussion might be less inhibited without senior management present.
- Take the time to celebrate! If your budget allows (and you should really plan for this), invite the team out for a social and team-building evening immediately following the workshop. Ideally the Project Owner and Senior Stakeholders can act as hosts – and pick up the bill!
- Introduction from Project Owner.
- Brainstorm what went badly, what went well, and what could be improved next time. Do this under several categories, possibly by splitting into sub-teams. e.g. Overall project, Design, Development, Testing, Hand-over, Vendor Performance, Project Management.
- If you have worked in sub-teams, bring the teams back together and consolidate the findings.
- Summarise and record lessons and recommendations.
The LfE Lifecycle
When starting a project:
- What do you bring to the piece? Based on your own experience, what do you expect to be the problem areas?
- Speak to other project managers. What is their experience? What do they think you should watch out for?
- Speak to team members. Have they done anything similar before? What did they learn from the experience?
- Look at the standard risk register. What in there might bite you?
- Consult the knowledge database, if you have one. It probably won’t help, but it can’t hurt.
During the project:
- Record any lessons as they happen, so that you don’t forget at the end. If you maintain a project workbook, this is a good place to keep them.
At project closure:
- Hold an LfE workshop.
- Add any relevant findings to the standard risk register (via the PMO).
- If someone is collecting contributions to the knowledge database, send them a charitable donation.
p.s. What about Agile?
Agile Scrum includes a Retrospective at the end of each Sprint. So the process has an inbuilt a continuous “inspect and adapt” cycle, which improves the capability of individuals and of the organisation. There is no need for anything else!