Lessons learned
When used well, lessons learned can contribute to the overall success of projects by re-using and building on approaches that have worked well and avoiding the repetition of previous mistakes. Lessons learned can also represent valuable intellectual property, deepen the relationship between suppliers and customers, and generally provide providing a competitive advantage. A disciplined approach to lessons learned can make an important difference to cost, quality and time.
Some of the failure modes encountered are:
- Lessons learned are often not captured well. There are several different ways in which this could be done more effectively, for instance by capturing lessons learned through the life of the project.
- Lessons learned need effective methods of communication. Stakeholders need to be made aware of what’s available and how to access it. Conversation is the most effective way to share lessons learned. Communities of practice (e.g. between project managers) may help as might encouraging new teams to share with previous ones, and the use of published guides.
- Adoption of ideas/outcomes from others may be hindered by cultural and behaviour. This may be linked to overall organisational culture, and to whether people are encouraged to learn from ‘mistakes’ or ‘failures’ and ‘successes’. Whilst all individuals should have a responsibility in this area it may help to hold project managers accountable for taking a pro-active approach to lessons learned.
Overall a mix of process and culture can hinder the benefits that could otherwise be gained from a structured approach to lessons learned. Our experience of lessons learned goes a bit further, as they are a key component of knowledge management approaches that we teach and facilitate for sharing learning, insights and experience within and between project and operational teams.
Lessons learned can be captured throughout the life of a project (or other kind of team), or at the end. The knowledge management literature1 refers to learning before, during and after.
Frequent, short, and relatively informal learning reviews during the life of a project or operational team are sometimes known as ‘After Action Reviews’. First introduced by the US Army, the intent is to capture and review lessons learned after any significant event, so that any corrective or supporting action can be implemented immediately. In a project team, these After Action Reviews could be carried out after a critical activity or at each stage gate. In an operational team they could occur as part of regular or periodic team meetings. Important ground-rules for these reviews include: everyone being involved, no blame, and ensuring that lessons are shared with everyone relevant whether inside or outside the team. A typical structure for After Action Reviews will include: a recap of objectives, what actually happened and how this differed from the intent, what can be learnt from this difference, and who to share the lessons learned with. What can be learnt covers both what contributed to things going well, and the causes for anything not going well.
A more reflective learning retrospect or history takes place at the end of a project or programme. It will explore the same questions as an After Action Review, but the recap of objectives and what happened will be a broader based exercise. We’ve facilitated this kind of learning review for a project in a workshop setting, with the originally planned and actual project milestones mapped out and annotated with post-it notes from the team members to indicate what went well and what could have been improved against these milestones. Again this kind of exercise will be most effective where there is involvement of the whole team, including the project sponsor(s), and agreement on what lessons learned will be shared with whom, how and when.
The third type of learning intervention takes place ‘before’ or at the start of a project or operational team. Also known as ‘Peer Assists’, this involves bringing together the members of the new team, and some or all members of previous teams who have lessons learned to share. In this situation, the new team lays out its draft plans, concerns, ideas and any specific questions for the visiting team. The visiting team considers and then shares what insights it can bring to the new team. The new team then uses these insights to revise its plans and also as input for its risk analysis.
As noted in the web briefing, the successful adoption of some or all of these three approaches for learning before, during and after will depend on the rigour with which teams and organisations implement the processes, and the nature of the supporting culture and behaviours. Incorporation of the learning processes into project methodology, facilitation through PMOs or other central groups, and role modelling by sponsors and management teams are examples of how such successful adoption can be enabled.
Further contributions on this topic are welcome.
You may also be interested in:
By Elisabeth Goodman and John Riddell, RiverRhee Consulting
Reference
1. Chris Collison & Geoff Parcell. Learning to Fly: Practical Knowledge Management from Leading and Learning Organisations. Capstone, 2nd edition, 2004
7 comments
Log in to post a comment, or create an account if you don't have one already.
Very interesting topic, thanks for sharing your thoughts. It is so true that most of the companies have so much experience of delivering projects but yet we don't find well structured approach towards lessons learnt. This is such a precious repository of great experiences which can be really handy for future projects, and will help in delivering projects in a better way. I think this topic should be part of every project review meetings and lessons learnt should be updated from day one till the closure of the project. This concept should be institutionalised across the organisation and metrics should be part of objectives for individuals. This should not be just left to only few individuals who are more willing, this should just come naturally to all. This will be so good not to face the same probem that someone else faced/solved before. Somehow, this is still not easy to achieve!
The benefits of and need for so much of our profession's best practice is as obvious as the reality of the King's new clothes. And yet are not "seen" by organisations until they are prepared to acknowledge it. Lessons learned is very much the same. It is so easy to ask; "why would we not do this?" It is so obvious that we should.The answer, as with pretty much everything else, is one of maturity. Organisations with a mature PPPM culture tend to do Lessons learned. And generally not as localised islands of good practice. It is however also and unfortunately true that some PPPM techniques are more valued than others. Hence whereas plans, risks, costs, changes are commonly part of the capability, making the case for investment in Lessons learned is not easy. Ah yes, it is another behavioural and cultural thing, and addressing these are really difficult as its about people, and plans, costs, risks etc are far easier to manage than people.So how to address this? Well two approaches come to mind. Firstly, the slow but steady chipping away - islands of good practice -mentioned by some. Sadly, likely to remain as islands. Secondly, finding a way to engage C level attention and develop a strategy to increase PPPM capability for sound business reasons - and include Lessons learned as part of an integrated solution. And oh yes, this is very, very hard to achieve.....but the journey is worth it.
I thought such was a good post and wanted to offer a suggestion that lessons learnt be structured around a number of existing documents with the philosophy that we do not need in my own mind to re-invent the wheel but instead use technonology to aid communications with the expectation of a requirement for rapid retrieval from a tablet device or similar.My first thoughts were to relate to the elements of APM's BoK and Competence Framework documents. However, if you think of an APM taxonomy rather than a glossary potentially you could also include:PM Standards i.e. BSI 6079PM Methodolgy i.e. PRINCE2Programme Management i.e. MSPPortfolio Management i.e. MoPOrganizational Maturity Models i.e. P3M3. It's just an idea, hope it appeals. Kind regards RichardSunny Jeddah
Wow, this is really detailed and interesting. I hope that there is going to be more discussions on "lessons learned" in the near future. There is so much that we can all learn here.
Valerie, it was good to see you referring to the role of a 'council' as an intermediary to ensure the sharing of lessons learned, as well as a process for embedding learnings into existing processes / procedures so that they can become the new way of doing things. These are 2 great approaches for ensuring that lessons learned are made use of. I've also heard of an organisation which has trained facilitators, whose role is to ensure that new project teams pick up on learnings from previous ones.Thanks for sharing your insights!Elisabeth
Absolutely the rigour applied to capturing, learning, and distributing lessons depends on the teams' and organisations' implementation of processes but more heavily on individual behaviours. At the end of the project the team moves on, so who picks up the action to ensure process improvements are implemented and lessons are passed to the next like project? So often this critical link is missing and relies on the conscientious to pass the improvement recommendations to the organisations' process improvement council, and include the lessons learned (or to be learned) in the organisations' knowledge capture tool - if they have one. At the start of any project, it should be the first action to search for similar projects and individuals who have worked on those projects and include them in a project risk review or similar. I am constantly amazed at the number of times this does not happen and am at a loss to know why. Project teams appear so anxious to get started on the work they ignore this crucial step and thus miss the opportunity to save their projects time and money. Having recently completed a project which strongly demonstrates the advantages of following up on a comprehensive lessons learned exercise, and landed with another project which shows the opposite, I am now on a personal crusade to influence my colleagues and company. As well as forwarding the improvements to our process council, my peers have been presented with the Good, the Bad and the downright Ugly. Id like to think Ive influenced them but fear its going to be a long haul to change the culture.
A really nice article. My thinking on lessons learned is 'yes we must do it', but it is often lost not because lessons learned are not done, but it is miss filed or just archived and hard to find the information that is relevant to your needs for the project you are putting together. As a management consultant that moves around companies and differing environments, I have found lots of great information stored away on shared file systems that are at the back of a server. Finding such information always enriches my thinking about the company. But, it means one must troll through a lot of information in order to discover what is relevant to my needs at that time. I believe we need to structure the lessons learned similarly to how we structure our benefits realisation planning which is linked back to the business strategy long-term plan. In this way, we can absorb a lesson learned around a particular strategic objective which is more focused and relevant to the objectives of my project, programme or portfolio. If I stuck around longer after an assignment that's what I would undertake to do, but the characteristics of my role mean we do the lessons learned collection and never get to file it in a structured manner, as I move on to the next client assignment. Maybe it's a paper I should right outlining my thinking around this subject matter?