As knowledge workers, we spend most of our professional lives in projects: analysing, advising, writing, designing, developing, creating and problem-solving. And we know we should use those projects to build our skills and capability – to learn. To learn as individuals, teams and organisations. We know we should, but somehow we don’t. Collectively, we are rubbish at learning from our projects. Why is that, and what can we do about it?
We need to learn from projects because we want to build on the experience. We want to get better, faster and more cost-effective with each project. Avoiding the pitfalls we have seen before and the costly rework that follows. We want to spread what we have learned to our colleagues, to prepare everyone for the next challenge. The argument for learning is clear.
Learning from projects at an individual level is not too bad. We have the personal experiences, and we carry the problems we encountered and the solutions we found in our heads. If we do lots of projects, and are good at this, we start to generalise and abstract; building heuristics that help us when we encounter a new situation. But what is in our heads is not necessarily useful to other team members and the wider organisation. Teams and organisations require a bit more structure to learn.
Why is learning such a problem?
There are practical and human reasons why organisational learning is a struggle. Mostly connected to when we do it and how we approach it.
Lessons learned reports are rarely effective. We tend to do them after the project finishes, almost as an afterthought. As a result:
- Everyone has forgotten what they did and learned.
- The project is over, and people quickly move on to the next activity. They are gone, and nobody is interested in history. The next horizon is more interesting.
- People face the pressure of the day job, especially if the project was layered on top of an existing workload. Team members have a backlog and are not interested in more work.
Beyond that, a typical lessons learned report is time-consuming, contentious, and unlikely to be useful:
- Lessons learned reports are usually boring and long winded. A typical plan has a 12-step process. Something to make the most enthusiastic quail.
- Office politics has its influence, and many learning reports become overblown exercises in arse-covering and finger-pointing. Especially if there were problems.
- For the poor soul charged with creating the report, it is a hospital pass. It will take time, you will get no thanks from your manager or your colleagues for the effort, and it is probably futile.
- These reports are usually heavy on the sequence of events and analysis, and light on actionable advice. Most end up on the shelf and are never referred to again.
So, it is not surprising that we struggle to find the space to do a good job of building organisational skills. The task is unattractive, of limited value, and too late.
What would an effective project learning solution look like?
Aware of the problems, how would we describe effective project learning solutions?
- Integrated into the project. It must not be an add-on or ‘would be nice’ activity.
- Simple. Whatever process you use must be low overhead. If you are going to integrate it with the project, it must not interfere with the project.
- The outputs must be easy to find and use.
- Offer real and immediate value. It must be clear how the outputs will help individuals and the organisation to do a better job. Not at some vague point in the future, but right now in the project.
- Ruthlessly people focused. The point of the exercise is to help people do a better job, not to do a thorough analysis. The analysis should only be there to support the recommendations. And those recommendations should be people focused and actionable by any team member.
Practical learning tools
There are methods that fit most of these requirements. My favourite I learned from BP many years ago – Learning Before, Learning During, and Learning After. I wrote about it a while back, but my recent experience with companies trying to build their capability to tackle new kinds of project shows it is not well known.
Learning Before deals with setting up a new project and is less relevant to project learning, but learning during and after is at the heart of effective skills and knowledge development.
The key method for integrating learning into the day-to-day project activities is the After Action Review (AAR). The AAR is designed for team learning. It was originally developed by the US Army and has found its way into many other types of organisation. AARs are used during a project to help the team improve, and are private to the team. They are fast collective debriefs. Not an exhaustive analysis, but capturing the team’s immediate thoughts after each significant step in the project, focusing on the key issues and identifying key actions.
The process is very simple. The team gets together and asks four questions:
- What did we set out to do?
- What actually happened?
- What were the differences and why did they happen?
- What do we learn from this and what will we do differently next time?
Classically, a single flipchart sheet divided into four is the quickest way to capture the answers.
AARs should be carried out immediately after the event so that everything is fresh in the team’s minds. They can be built into team meetings as a routine review and should not take more than a maximum of 15 minutes. Most of the ones I have taken part in lasted about 5 minutes.
So a good after action review is built into the project, simple, of immediate value (how the team can do better tomorrow), and helps people.
A Project Retrospect covers ‘learning after’. It is like a larger scale After Action Review. The key questions are now:
- What were the objectives of the project?
- What did we actually deliver?
- What went well – and why?
- What did not go so well – and why?
- What are the key messages we would pass on to the next team to tackle something similar? What is our learning for the future?
Think of it as a message in a bottle to the future. Either your own future or others. What are the few key points you want to make for the next team to try something similar? Not a blow-by-blow timeline of the project, but the few things that it will speed their project or the traps that will derail it.
The retrospect is best done as a face-to-face meeting. That makes it much easier to get the necessary consensus. It need not be a major exercise; a couple of hours has been sufficient for most of the projects I have taken part in. And the output should be short; a couple of pages are ideal, and focused on actionable advice to real people. Enough background and context to understand why those are the recommendations, but only that. If it is too long-winded, people won’t use it.
Do these tools work?
There are plenty of examples of the benefits of these light-touch, low-overhead learning methods.
In the UK National Health Service, AARs allowed teams to build learning into their very busy schedules while providing a ‘safe space’ for people to discuss problems, particularly concerning patient safety. This has helped reduce the risk of poor outcomes for patients.
Emergency services have long been advocates of AARs. Regular use increases team responsiveness and accuracy of decision making. As with the NHS, pressure situations where integrating previous experience into team expertise and processes are vital.
A multi-national marketing organisation created a short project retrospect for every campaign they undertook; tagging them by geography, product type, target audience, etc. Faced with a new brief, they could quickly call up the learning from previous projects to get a fast start and maximise the chance of success.
I have been involved in several multi-day strategy and creativity workshops, where the facilitation team used AARs to adjust quickly to the participants’ needs. At each stage, the AAR helped us check whether everything was on track and gave a direction for any course corrections. Those workshops were much more effective for the participants, the other facilitators, and for me.
These methods work!
There will still be difficulties
Of course, things can still go wrong. Organisational politics is often a problem. People may be uncomfortable discussing problems and failures, there may be rivalries between departments and teams, participants may feel there is a ‘party line’ to follow. I once had to take a senior manager aside and ask them to leave a project retrospect meeting because they were stopping the rest of the team from getting to some important points. The manager wasn’t even trying to be obstructive; just their presence was enough in that culture to stop open discussion.
And egos. Everyone should leave their egos at the door. But the loud, the confident, and the hierarchically minded are a problem. The goal is that everyone has a voice, and everyone will be listened to. If it is difficult, you may need a facilitator to help you; perhaps from another project or part of the organisation.
Integrating the after action review and project retrospect into your project process gives a proven, low overhead way to maximise project learning. If you don’t use these tools yet, try them.
Some basic notes on learning before, during and after.