Friday 30 October 2009

After Action review - the 4 questions

The structure of an AAR is very simple. It consists of asking four questions. However the value comes in the quality of the answers, so it's worth getting those questions right if you can.

1. What was supposed to happen? The first question is asked about the objective of the activity, and the target performance. We have often found that the first few times you ask this question, people may turn out to have been confused about the objective or the target, or else no clear objective was set. One of the by-products of AARs is that they promote objective-setting.

2. What actually happened? The second question looks at actual performance. If you are conducting an AAR, you need to establish ‘ground truth’ with this question. You are looking to determine reality, rather than opinion. Metrics are really useful here. In training exercises, or reviewing sports events, use video, or impartial observers to determine what actually happened.

3. Why was there a difference? The third question seeks to understand why a particular result occurred. Perhaps you did better than expected; perhaps you did worse than expected; perhaps you met your target. What were the factors that determined the result? Another way to ask this question, if the first way doesn’t work, is ‘What went well, and what did not go so well?’ Here it is really important to get to root cause, and not to stop at a superficial level. You are seeking, through dialogue within the team, to find the root causes behind performance improvement or performance slip.

4. What have we learned? The fourth question asks about the learning, and should be expressed in terms of what will be done differently the next day (or, in cases of over-performance, what should be repeated the next day). Here you move from analysis of the activity, to ‘what are we going to do about it’, and ask, what action needs to be taken? Once you have decided ‘what are we going to do about it’, then you need to assign the action to ensure it gets done. Much of the time the action lies with the team. If the team cannot fix the action, there needs to be an escalation route.

The answers to these questions can usefully be recorded on a one-page pro forma, or a marked up flip chart, which can be collected for future reference. Note that although we show here the questions in sequence, what typically happens is that question 2 will identify a few areas to be discussed, and then questions 3 and 4 are asked for each of these areas in turn.

Here's an example AAR from a refinery maintenance program, which shows the level of task detail to which AARs may be applied. This example comes from a shift team in Singapore, who were installing trays within a refinery unit (a tray is a particular piece of equipment inside a refinery column, and needs to be fitted by someone working at height).

1. What was supposed to happen? 1) To install trays, with weir heights and downcomers within tolerance. 2) To hold tray assembly in place with appropriate hardware, e.g. bolts and nuts, clamps, washers, slide fasteners, etc.

2. What actually happened? 1) Tray clearances were not within tolerance. 2) There was a shortage of hardware.

3. Why was there a difference? 1) Workers were using measuring tapes to adjust the clearances resulting in a need for repeated re-working. 2) Workers were transporting the hardware up the column in bulk, resulting in hardware being missplaced, dropped, or not following vendor’s instruction on the appropriate type of hardware to be used.

4. What have we learned? 1) Use standard blocks prepared to the required dimensions for adjusting weir height and downcomer clearance. 2) Put all the appropriate hardware in place on the tray sections at ground level before transporting up the column.

Actions that need to be taken 1) Request the workshop to construct a series of standard blocks. 2) Update daily orders for tray installation.

Although the learning here is only about small things – tray tolerances, clamps and washers – an increased ability to avoid small mistakes, based on day-by-day routine learning, can give a massive performance improvement at the end of the project.

No comments:

Blog Archive