Lessons learned web briefing v1.

0 3rd April 2012

APM Web Briefing - Lessons Learned

Introduction In project management we rarely seem to apply Lessons Learned - Why does our profession continue to make the same mistakes? Lessons Learned (both good and bad) can possibly be the most powerful project management tool available. The case for change In their research on what helps projects to succeed and what contributes to failure, Cranfield University School of Management found that the biggest differentiating factor between organisations that generally succeed with their projects and those that don't is "the willingness to publish and distribute lessons learnt". The knowledge and project management literature suggests that lessons learned processes are rarely applied. When they are applied they do not work well and they fail to deliver the intended results. Factors related to culture, people and their behaviour are those most likely to negatively influence the dissemination of Lessons Learned in an organisation. The project management publication PM World Today recently posted an editorial on Lessons Learned but Knowledge Lost (Pells 2011). Wideman (2011, p.1), a globally recognised project management expert stated: ...in spite of all the technology that is available to us today, we have not yet found a presentation format that captures the essence of this wisdom in a way that is relevant to future usage, readily searchable and easy to store. ...we have a serious cultural problem. ...we are probably condemned to continue to throw away the valuable resources. When and how to capture lessons learned We should not wait until the end of a project to carry out Lessons Learned. The danger of waiting until the end of a project to identify, capture and analyse lessons is that most project team members will already be focussed on the next project. Project momentum will have slowed down and most of the team will see this as a 'box ticking' exercise. As a result, only a fraction of the lessons that could be valuable to future projects are recorded and passed on. Even if an organisation has an effective method of communicating its lessons and learning from them, the most important element (identifying and capturing Lessons Learned) will have been compromised. Projects are generally split into a number of phases, milestones or gates and will overlap with other projects that are approaching the same phase in their project life cycle. Lessons Learned Reviews should be carried out at the end of each formal phase of the project and any learnings rapidly utilised both within the project being reviewed and in other related projects. Setting up a Lessons Learned log during the project start-up will help to establish the process as a core part of project management. Encouraging its use, and regularly reviewing it as part of the risk management process will also make it more meaningful and relevant to the work of the team. Ongoing capture of learnings as you go will also make it a lot easier to incorporate Lessons Learned in the end of project report.

Lessons learned web briefing v1.0 3rd April 2012

How and when to share lessons learned It is not enough to close out the project and to create a Lessons Learned report - the reports have to be made available to others in a way that makes them want to read and apply the lessons. The key to this is effective communication: Organising the critical information in an easy to understand way that that makes its relevance apparent. Ensuring that the different stakeholder groups are aware that the information is available, and that they know where to find it. Presenting the information in such a way that people can quickly extract it and turn it into useful actions. The best way to prevent the same mistakes being repeated is to embed new learnings into the relevant organisational processes (see next section). Where Lessons Learned do not relate to a specific process but may benefit future projects, helpful prompts can be prepared in the form of published guides or aide memoires. The success of passing on Lessons Learned in a written form will depend on the skill of the writer e.g. dry history books vs. those that bring the past dramatically to life. A large amount of knowledge on lessons will always remain with the individuals involved: what can actually be captured in a report is only a small percentage of the whole. Therefore, when the content of a Lessons Learned report appears useful for a current project, it is a good idea to followup with a conversation with the subject matter expert involved in generating the Lesson Learned. The only way real learning gets shared is through conversation. The trick from a business point of view is to enable that conversation. Getting people together face-to-face is the ideal way to do this. Telephone conversations are a valuable alternative. E-mail or discussion forum dialogues can be useful. Social media such as twitter, blogs etc. have a great potential for enabling conversation and therefore the ability to share knowledge or lessons. A key arena for the effective sharing of Lessons Learned is a community of practice (a group or network where people are brought together by a common interest) as a lot of the context of the learning will be understood, relationships can be built which will encourage openness, and interest in avoiding repeated mistakes will be at its highest. A forum of project managers within a company is an example of a community of practice. Project management forum meetings could have an agenda item to share lessons learned from all projects and from the whole team. These lessons should be positive ones as well as negative ones. Sharing the lessons will heighten awareness of problems, help people spot where they are experiencing the same thing and find solutions to prevent them from happening again. It will also allow those involved to highlight the good things that are happening as opposed to just focusing on the problems. Adoption Issues, motivation and ways to gain adoption A critical step for new projects is the review of relevant Lessons Learned. PRINCE2 does mandate it, but does it really happen in a meaningful way? In problem situations, the PM is very rarely challenged as to their awareness of whether a given problem had occurred on a similar project, whether it was therefore foreseeable, and to what extent had they taken measures to avoid its recurrence. Perhaps more focus on holding project managers to account in this way would result in adopting Lessons Learned processes more effectively.

Lessons learned web briefing v1.0 3rd April 2012

A potential issue for Lessons Learned is that there are personalities involved and/or an environment which is not conducive to working this way. In many instances a project teams ability to implement lessons will be outside its influence: the lessons may relate to an overarching process or they may just be too late for that project to adopt. For instance, corporate procedures might have been developed by another part of the business. They may have been applied indiscriminately to the entire organisation and they may be completely inappropriate for the project in hand. In these circumstances the problems are often absolutely foreseeable but occur anyway because the business mandates adherence to their procedures. Even if the business does not mandate adherence, it is often extremely difficult to obtain permission to deviate from those procedures. The Lesson Learned process therefore needs to consider who is responsible for taking the lessons forward and unblock the road to improvement. There is often a perception when a new project is set up especially if preceding projects have been problematic - that a conscious effort should be made to wipe the slate clean. This usually means an entirely new team (immediate lack of continuity and no first-hand experience of what went before) with new opinions about what will work and what wont. Too much reference to an earlier unsuccessful project is generally viewed as not a good thing, so even if a Lessons Learned report does exist it may never be looked at. In such situations it is little wonder that the same mistakes are made again, and even worse, mistakes are made on the new project in areas which were successful on the earlier project. In large organisations project managers can be competitive with a real desire to improve upon others successes with project managers actively attempting to establish what went well and what could have gone better and making tweaks to an existing formula. However this competitiveness could result in an adversarial approach with project managers deliberately adopting a completely different approach to that of a colleague (rival?) so as not to be seen to be doing the same thing, regardless of how successful the colleagues project may have been. More worryingly this rivalry may result in a successful project manager actively avoiding to pass on good points to others, or to flag up obvious pitfalls. In addition, if project metrics are translated into performance measures this can exacerbate the competitiveness between project managers and create a negative culture discouraging knowledge sharing. Making effective use of Lessons Learned is a cultural trait the alternative and easier option is to sweep problems under the carpet. However, the trigger to invest in learning from mistakes (and successes) has to be based on individual experience. One that highlights the value gained from learning lessons. We remember to go and write Lessons Learned reports far more often than we go and look at someone elses. Experience, being the tough teacher it is, means that there is a good chance you remember your own lessons, so there is even a temptation to not write them down nobody looks at them anyway do they? Edited by John Riddell and Elisabeth Goodman, with contributions from Adrian, Wilson Chiu, Stephen Duffield, Colin Hewson, James N, Neilgee67, Paul Rayner, Simon Springate, and Pat W, and input from Mark Hopkins 3, Phillip Lo Castro, Oldloggie, Marian, Scott Walkinshaw, Graham Woodward, Richard E Renshaw.

Lessons learned web briefing v1.0 3rd April 2012

See the original discussion at http://www.apm.org.uk/content/lessons-learned. About the editors Elisabeth Goodman is the owner and Principal Consultant of RiverRhee Consulting and a full member of APM. She has 25 years' experience in Pharmaceutical R&D, where she has held management roles in information and library management, and internal training and consultancy roles supporting business teams on a global basis. Elisabeth is an experienced and certified practitioner in change management, Lean Six Sigma, MBTI, and an expert in knowledge management, with a proven track record in improving team performance and leading business change projects. elisabeth@riverrhee.com, http://www.riverrhee.com, 07876 130817 John Riddell is an Associate with RiverRhee Consulting and a full member of APM. He has held technical, operational and project management roles in pharmaceutical manufacturing working with both small and large teams from a local to a global basis. John is a certified practitioner in Lean Six Sigma and is highly experienced in knowledge management. He has developed a successful programme to coach leaders in developing teams that have multiple cultures and are spread across global locations. john@riverhee.com, 07765 157363. Web briefings Web briefings are the developed from the APM Community, an online community of project professionals. They result from discussions and questions asked within the community, the content is developed from users responses and edited by APM. Web briefings are constantly evolving within the online community and are intended as a guide to issues within the profession. See all APM web briefings.