After one of the AARs we did, a participant brought up the issue of a repository for AARs:

“If we are going to embrace AARs for various events and activities, I have a couple recommendations. The only reservation I have about tools of this sort is that an evaluation is made and then everybody forgets what form the conclusions took and where it was stored so they can quickly and easily refer to it again. Sometimes people forget that an evaluation was made and don’t bother to look it up again.

I recommend we create an AAR folder somewhere on a network drive and make sure all AARs from any department or source be placed there. If some need to be confidential, password protect them. Also, some kind of standardisation should be adhered to so that there is some consistency. An AAR template or form perhaps?

Additionally, I think AARs for repeating or similar events should not be separate documents but be updated within the same, original document. Otherwise observations and conclusions get siloed and you hinder the benefit of accumulating knowledge.”

Look at the Return on Effort

Over the last 20 years, I have tried most approaches. I suppose the rule that has worked best for me is,

Put another way, do what is “good enough” and get feedback to see what else you should do. Don’t waste time designing something that is more that your “customers” or “users” are asking for. Let the solution emerge as you discover what people really need.

It is tempting to write lessons-learned documents but if the culture is not one where people routinely pull lessons from a “knowledge base” and if leadership does not routinely force people to check lessons learned, then they will only gather dust on a library bookshelf or hard drive somewhere.

Never used lessons-learned. At one company I worked for, the engineers spent months writing the lessons learned from the big aerospace program they just completed. Being a believer in lessons learned, when I got assigned to the next big program I went to the library to look at that document… I was the first person to touch it in five years! No one on the new program had bothered! Engineers are like many people who work in NGOs: They are super busy.  They like coming up with their own solutions. And they tend not to know how to search for information or where to look.

The best approach is to embed the lessons learned into the work routine that people are already doing, making processes smarter, making it easy for them to access the lessons learned. It is always best to have people pull knowledge based on their own needs rather than have it pushed on them, where they have to figure it out how to use it.

Reusing travel knowledge. Consider this example. At one NGO, whenever  someone returned from a country visit, the travel department interviewed them, using a structured set of questions. They would ask about lessons, people and situations to watch out for, who to trust, protocols to observe, airports and customs, and so on. The travel agent then wrote up the notes including the person’s name and contact information and entered it into a simple database. As part of their proces, whenever the agent booked travel for someone, she would search the database and offer to send an email to the traveller with the information about the country and the contact information.

This system was very popular because 1) The agent did the search for the traveller and interpreted it for them, 2) the information came just when the traveller needed it – the process of arranging travel, 3) the information came in the form of an email (which they used a lot), and 4) the traveller got contact information so they could ask questions of the person who had been there. The last point is important: people like talking to other people rather than reading (stale) reports; it lets them ask questions that are relevant to them.

When it comes to AAR, the most important thing is to get the knowledge used by those who need it. And then get it used more widely, if necessary.

I will write more about that in the next blog.