Why do lessons not get learned and what can we do about it?

“We learn from history that we do not learn from history.” - Georg Hegel

Googling ‘proportion of projects that fail’ yields a variety of articles that quote an alarming percentage of 70%. It is important to note that there has been no significant change in this figure in decades. Therefore, it superficially appears we are condemned to repeat our mistakes. Worse still, we waste valuable resources undertaking an exercise that either does not properly capture the relevant lessons or is not used.  

It should of course be understood that not all learning is about what went wrong but in how to repeat what went well. Most importantly it should direct future actions to improve future business activities to achieve better outcomes.

Why do we repeat our mistakes?

Before we work out what we need to do to redress this we need to understand why. While I will discuss lessons learned in the context of project delivery, the principles are equally as applicable across other business environments. There are at least four main reasons why our efforts to learn lessons fail. 

We don’t collect the lessons learned properly or at all in the first place – This may be because the appropriate personnel are not available or uninterested in contributing, as is common at the end of a project. There are often sensitivities surrounding blame and culpability that directly skew or influence the findings. Organisational culture, seniority of those involved and the skill of the lessons learned facilitator all contribute to the integrity of the exercise. 

We don’t communicate the lessons learned effectively – The outputs may be documented but not used or else the message lost in the noise, having to compete with many other operational communications.

We think the lessons don't apply to us – Over optimism and an over-belief in ability generally makes us believe it will not happen to us. This project will be different….

We want to get things done – We tend to want to start on activities that contribute directly to the bottom line. Planning, which includes incorporating lessons learned, is often minimised in our haste to get started with the ‘real work’.

So we need to address each of these points in turn to more fully harness the power of past experience.

So what do we do?

The most common approach to gathering the information and determining the lessons is through a workshop. However, interviewing selected individuals beforehand should make the workshop more effective and potentially reduce its duration. An impartial and sufficiently empowered and senior facilitator is a prerequisite as is an organisational culture that facilitates learning for its collective benefit. Mandating budgeting and scheduling for lessons learned activities and their inclusion within project governance are ways an organisation can ensure they are completed.

Once lessons are documented we need to ensure they are enacted when appropriate. They should be presented to relevant personnel rather than merely communicated via a medium such as email or a written report. This can be done at intervals, perhaps presenting lessons from various sources for the sake of efficiency, or at the beginning of a new project or even project phase. It may even be undertaken immediately after an outcome has been experienced, either good or bad. Indeed, it is preferable to undertake lessons learned while memories are still fresh.

The recipients need to be actively involved in determining how future risks can be mitigated. Lessons should be grouped and indexed across a variety of categories. For example, against aspects such as project management, resources, technical, communication, business processes, requirements, design, implementation and testing and against the project phase. This will allow them to be later retrieved. A selection of categories and sub-categories is listed below.

Project Management - Project Planning, Resource Management, Risk Management, Change Control, Procurement, Budget Management, Quality Control, Status Reports, Vendor Selection

Technical Management – Requirements, Specification, Test Plan, Construction, Testing, Rollout, Training, Documentation, Vendor Management

Human Factors – Communication, Team Experience, Interaction with internal stakeholders, Interaction with Customer, Interaction with Management, Management support, Quality of meetings, Vendor interaction

Overall - Customer Satisfaction, Technical Success, Quality product, Product Accepted, On Time, Within Budget, Met Project Objectives, Met Business Objectives

Where lessons are collated and communicated, there are other ways their implementation may be enhanced. The inclusion of lessons learned in risk management and planning processes can be effective. Particularly common lessons should be included within governance processes, thus ensuring a project does not advance until after they have been satisfactorily addressed. The formation of a community of project managers is an excellent way of keeping lessons current and thoroughly communicated.

Where used, written reports of lessons learned should be concise with the pertinent points clearly presented to allow them to be easily understood and extracted for future use. A report could contain the following headings:

• Executive summary containing an overview of the scope and rationale of the exercise and other information such as attendees of workshops. The scope of such an exercise could a project running over schedule and over budget because the required inspection of the finished product was more extensive than had been estimated.

• Findings, each with a unique identifying number and with a particular aspect of the overall scope of the exercise, being considered. Decomposition in such a way will aid both the identification and analysis of individual lessons and its applicability against future projects. Each finding will consist of the following: 

◦ An overall statement. For example, poorly defined requirements made difficult determining the appropriate depth and amount of inspection undertaken.

◦ Causes – Listing the reasons why this had occurred. One such cause in this example could be a poorly written client specification.

◦ Recommendations – Describing how the impact could be eliminated or reduced in the future, i.e. early submittal of technical queries could have resolved this.

• A section containing the signatures of workshop attendees signifying acceptance of the content of the report.

In some instances the lessons learned can be put upon a poster with further distillation of  the essential points for maximum impact.

Conclusions

It is advisable that several of these techniques are used in conjunction with each other to increase the likelihood of the lessons being consulted and then used. It also goes without saying that an organisation’s approach to learning from experience should evolve over time to improve its effectiveness.

An old saying offers that you should avoid mistakes as they lead to embarrassment but you should also embrace failures as they lead to knowledge. A structured approach to learning through experience should equip an organisation to achieve both of these goals.