Feature

posted 12 Sep 2001 in Volume 5 Issue 2

Learning after doing

Using the retrospect process to harness knowledge

In the last of a three-part series, Chris Collison and Geoff Parcell draw on their experience – and their recently published book, Learning to Fly – to describe another of their practical tools for learning, before, during and after any business activity. This month’s article explains the ‘retrospect’ process, the tool used by BP for learning after doing.

Have you ever wondered what it must be like be a professional footballer immediately after a defeat? We see the deflated team trail dejectedly from the pitch, but what happens next?

At primary school, the dressing rooms could be charged with stinging recriminations; egos were punctured as last week’s hero became this week’s villain.

“6-5! Collison, you cost us the game – why didn’t you pass the ball?”

6-5. Why didn’t I pass the ball?

In professional circles, of course, things are somewhat different. The coach will bring together the team immediately after the match – those who have played and those on the bench who will play in future games. Together, they will go through a review of the game – the strategy, tactics, teamwork, the good and bad points. Together, they will watch videos, watch them again, review decisions and identify what they could have done differently, making a mental note to build this into future games, especially those against the victorious team this time.

So why is it that in business, we all too often slip to something closer to the primary school model? Even when we do expend time and energy in reviewing a project, or a piece of work, the organisation too often fails to take advantage of its own history.

Our experience with project close-out reports and post-project appraisals is that they simply don’t get read most of the time. Usually this is because they don’t seem to be written with the reader in mind. Somehow they lack timeliness, completeness, passion, even credibility, especially when they become a catalogue of reasons why ‘it wasn’t anyone’s fault’.

According to Sir John Browne in his 1997 Harvard Business Review article: “Most activities or tasks are not one-time events. Whether it’s drilling a well or conducting a transaction at a service station, we do the same things repeatedly. Our philosophy is fairly simple: every time we do something again, we should do it better than the last time.” That’s exactly the philosophy that he practices when merging with or acquiring companies.

In many parts of its business, BP has been using the process called a ‘retrospect’ as a tool for ‘learning after doing’.

What is a retrospect?

A retrospect is a simple meeting, called after the completion of a significant piece of work – at the end of the war, rather than after one of the battles.

It is a way to ensure that a project team feels ‘complete’;
It is a way of transferring lessons immediately to the next similar project that is about to start;
It is a quick and effective way of capturing the knowledge before the team disbands, securing the lessons learned for the benefit of future project teams.

The retrospect meeting lasts from a couple of hours to a couple of days, and requires facilitation.

Revisit the objectives and deliverables of the project;
Ask what went well. Ask ‘why?’ several times;
Ask what could have gone better. Again, ask ‘why?’ several times.

However, unlike an after action review, a retrospect is conducted in more depth, taking anything between an hour for a simple project, to up to two days for a complex alliance involving multiple companies. The other significant difference is that a retrospect has the specific intent of capturing lessons and insights for a future project, not just a way for a team to reach ‘completion’. There is a direct customer for the output of the meeting. Indeed, if possible, that customer should be present to pick up the full richness and subtleties of the interactions, subtleties that the capture may well fail to document.

The retrospect in practice

Here are the specific steps and facilitator’s notes that have been successfully applied for over six years in BP.

1. Call the meeting

It needs to be a face-to-face meeting. Videoconferencing can be used – it’s better than nothing – but a physical meeting is generally more effective. If you are concerned that people will not be open at the meeting, you may also need to conduct one-on-one interviews to supplement this. Don’t try and conduct a learning capture by e-mail. Hold the meeting as soon as you can after the project ends, ideally within a couple of weeks. Memories fade if you leave it much longer, events become glossed-over and the past can develop a rose-tinted hue.

Consider positioning the meeting as a celebration if appropriate. The following quote, take after a project building retail sites in Japan illustrates the point: “I guess it was successful because the event itself had been a success. It was a very upbeat meeting, so it wasn’t seen as a witch-hunt. It was done within the spirit of a celebration – T-shirts were handed out.”

Facilitator’s notes

If possible, the venue for the meeting should be closely related to the work environment of the project itself. The project office or ‘war-room’ is ideal, as it will bring context flooding back for the team;
Avoid neutral or hotel-based locations. The retrospect is about capturing the reality of what happened, and sterile hotel conference rooms can lead to sterile conversations;
Allow for approximately 20 minutes per person, or half an hour if it was a lengthy, contentious or complex project;
Ensure that a variety of workshop materials (eg, Post-It notes, flipcharts etc) are available.

2. Invite the right people

If a similar project is due to start, or is already underway, then there is great value in the new project team attending, so the knowledge can be transferred in real-time as soon as it is surfaced.

The project leader needs to attend, as do key members of the project team. Ideally, the project customer/sponsor/client should attend, at least for the first part of the meeting. However, there is a need to be sensitive to the presence of a highly-placed sponsor on the meeting, as it may inhibit some team members.

Ask the project leader/co-ordinator/manager to schedule the meeting. He or she has most ownership, knows who needs to attend, and still probably retains some influence in the project team. In the call to attendees, announce that the purpose of the meeting is to make future projects run more smoothly, by identifying the learning points from this project.

Facilitator’s notes: if members of a future project team are able to attend, try to maximise the informal, social time. Split the meeting across two days with room for dinner and bar conversations. Enlarge the coffee breaks at key points in the day. You’ll find that once in the same room, people simply cannot stop sharing.

3. Appoint a facilitator

You will need a facilitator who was not closely involved in the project, otherwise the meeting may concentrate on ‘what we did’ rather than what the next team should do in similar circumstances.

If the facilitator is remote from the project, or the subject matter is complex, then he may need to do some preparation (eg, discussions with key players), more in order to understand the hot issues than to understand the content in detail. The facilitator should also be outside the line-management structure, and the meeting needs to be clearly separate from any personal performance assessment.

Facilitator’s notes:

Ask people to introduce themselves and their role. This may feel like overkill for a project team who have been working together over a year, but it can be surprising what can be discovered;
Make sure the project team ‘owns’ the meeting. It’s their meeting not yours, so be prepared to compromise over meeting structure if necessary. The important thing is that all participants gain a fair share of air-time;
Start the meeting by reiterating the purpose – this is not to assign blame or praise but to ensure future projects go even better than this one. Better still, have the project sponsor do this;
Set an atmosphere of openness. If necessary you can introduce ‘rules of the game’. There are no right or wrong answers. Affirm that no record of the discussion will be distributed without the agreement of all the participants. Names can always be dissociated from quotes if necessary;
In a big meeting, ask someone to take detailed notes for you, including verbatim record of key quotes and soundbites. If you can gain agreement from the participants, consider using a tape recorder, but be very sensitive to the impact of this on the conversation.

4. Revisit the objectives and deliverables of the project

This is the point at which you ask what the project team originally set out to do, and what was actually achieved. The facilitator may want to ask the customer or sponsor if they got what they wanted. It is then valuable to ask if the deadlines were met, and the satisfaction measures achieved.

Facilitator’s notes:

Try and find the original ‘criteria for success’ to check whether the project delivered these;
You can ask for original definitions of timescale, cost and resourcing.

5. Revisit the project plan or process

In long or complex projects, it can be beneficial to revisit the project plan, compare it with what actually happened, and identify any deviation from the plan.

With the team, construct a flow chart of what happened, identifying tasks, deliverables and decision points. In this way, you can identify those parts of the project that experienced delays or were completed ahead of time, those parts that were particularly efficient or inefficient, and those parts where the team was unclear over what really happened.

6. Ask, ‘What went well?’

Always start with the good points. We should be seeking to build on best practice as much as we can to avoid repeat mistakes. Ask, ‘What were the successful steps taken towards achieving your objective? What went really well in the project?’ Also, ask ‘why?’ several times. This will get you to the root of the reason. If time is short, a good approach is to ask people what they see as the greatest success factor. If this has already been covered, ask them to choose the next most important factor.

Facilitator’s notes: go round the room asking each individual for their successes. Don’t let the loud ones dominate the meeting. It is vital that everyone is asked, and heard. Ask the quieter members for their ideas first, to prevent them hiding behind ‘I was going to say that too’ excuses. The chances are that these insights will be less widely known by the others in the group than the opinions of the more vociferous staff. You may need to give participants a couple of minutes thinking time before anyone speaks, to write down what their successes were without being influenced by what others might say. It may be best to start with the project leader, as they are likely to have the best insight into the details of the project.

7. Find out why these aspects went well, and express the learning as advice for the future

Identify the success factors, so they can be repeated in future. Try and deal with facts. Feelings need to be acknowledged, but future recommendations have to based on agreed facts. Questions to ask include: what repeatable, successful processes did we use? How could we ensure future projects go just as well, or even better? And, what would your advice be to future project teams, based on your success here?

The main task here is to keep pressing for specific repeatable advice.

“We had several group members who picked up on the ‘recommendation-making’ angle early on. This helped to set an example for other group members.” (Keryn Smart, Australia.)

Facilitator’s notes:

This part of the meeting will be a conversation. You have two options: the first is to ask the probing questions (and let the conversation develop) as each person identifies their success factor(s). The idea is to reach group consensus advice through conversation. In a close team this will happen naturally. An alternative approach, useful if the team is more subdued, is to identify all the issues first, then choose the ones to work on as a team;
Almost certainly, as discussion continues, ‘bad’ points as well as good will be discussed. Don’t try and stifle this; let the discussion continue as far as identifying consensus advice, then return to the next person’s success factor. Asking for success factors is just a way to get the topics into the room, and should not be used to stifle discussion if the negatives creep in.

8. Ask, ‘What could have gone better?’

There are bound to be some areas where things could have gone better, where pitfalls were identified too late and where process was sub-optimal. Find out what factors participants believe hindered the project’s progress.

Don’t allow people to disregard the comments of others – rather, encourage them to say, ‘My view of the incident was different’ instead. Remember that everyone’s perception is equally valid.

Facilitator’s notes: again, go round the room and ask each individual. It often makes sense to start with the team leader, who you have already asked to set the tone in being open and frank. If he admits that things could have gone better, the rest of the team will open up as well.

9. Find out what the difficulties were

Identify the stumbling blocks and pitfalls, so that they can be avoided in future. The following questions are useful:

Given the information and knowledge we had at the time, what could we have done better?
Given the information and knowledge we have now, what are we going to do differently in similar situations in future, to ensure success?
What would your advice be to future project teams, based on your experiences here?

Facilitator’s notes:

You have to ensure that this section of the process does not become a witch-hunt or a finger-pointing exercise. It is OK to let people have their say, but you may have to keep pulling them back from the problems of the past to ask, ‘So what would you do differently next time?’
Consider writing on a flip chart, ‘What about next time?’ to remind people of the focus of the meeting;
Again, you have the option to hold the discussion as each person identifies their points, or to collect the points and choose which to discuss.

10. Ensure that the participants leave the meeting with their feelings acknowledged

You do not want anyone to leave the meeting feeling that things were covered up, or that valuable effort was not acknowledged. Access to this can be achieved by asking people for a numerical rating of the project. Ask, ‘Looking back, how satisfied are you with this project? Give marks out of ten.’ Many people will say the project was fine, and then give it eight out of ten. This enables you to ask, ‘What would have made it a ten for you?’ and so access residual feelings of dissatisfaction. Sometimes you might want participants to reflect on the impact of the process on the result. It is possible to still achieve a great outcome via an imperfect process.

Facilitator’s notes: it is worth giving participants a few seconds thinking time to write down their score before asking them to call it out, so they are not influenced by other people’s ratings.

11. What next?

If the project team is going straight on to a similar project, it is useful to follow the retrospect with a planning session for this.

Facilitator’s notes:

If the previous project went badly, it will be worth reminding the team that they will need to act on the knowledge they have just uncovered if they want future projects to run more smoothly. Ideally, they should embed the knowledge into revised team processes, procedures or structure;
Press for people to commit to actions, particularly on the difficult issues;
If there was dissatisfaction in the room – perhaps someone felt a lack of acknowledgment, for example – there may be steps that could be taken to address this, even at this late stage in a project.

12. Recording the meeting

It is vital to have an interesting and well-structured account of the meeting and its outcomes. A suggested framework is:

Guidelines for the future;
History from the project to illustrate the guidelines;
Names of the people involved for future reference;
Any key artefacts (eg, documents, project plans etc).

This determines what you need to record from the meeting.

The direct use of quotes is also one of the most powerful ways of capturing the depth of feeling, and of creating a summary that is likely to be read. “Nothing turns me off more than a ten-page report full of abstracted motherhood statements. I can already feel my eyes beginning to close...” (Chris Collison.)

You see? Sprinkle selected quotes liberally throughout the write-up. Quotes should be attributed to a person wherever possible. It goes without saying that the person attributed with any quote will need to agree to its inclusion.

Also record as accurately as possible what the recommendations are for the future. Often the recommendations won’t be clearly stated in the meeting, and the facilitator will need to do some re-wording of the meeting records. Express the recommendations as clearly, measurably and unambiguously as possible. The acid test of the document’s usefulness is to ask yourself, ‘If I was the next project leader, would these lessons be of any use to me?’

Ensure that you circulate the write-up around the participants for comment. Make sure nobody was misquoted, and that the facilitator’s wording of the lessons really reflects the views of the team. Once agreed, distribute the final copy to the team. Consider also who else could benefit from the content and send it to them.

What if a project was just starting up in three years time? How would they be prompted to read your record of events? The final stage is to find somewhere logical to store this invaluable document, somewhere where it will get read in detail and applied to future projects. Somewhere a group of people will review it and treat it as an asset to be embedded it into future company processes and guidelines.

Incidentally, to this day, I don’t know why I didn’t pass the ball that time when we lost six goals to five. But I made sure I didn’t make the same mistake again that season.

Inside Knowledge is the premier global magazine focusing exclusively on knowledge management. For a subscription, please see www.ikmagazine.com

Learning to Fly was reviewed in the July/August edition of Knowledge Management. If you are a subscriber, you can access the review in the Knowledge Management library. Visit: www.ikmagazine.com.

Chris Collison and Geoff Parcell work with knowledge management, learning and innovation at BP. They can be contacted at chris.collison@bp.com and geoff.parcell@bp.com respectively.