When Your Project is Done, It’s Not Dead

A Guide to the After Action Review Process

I think we all know in principle at least that some sort of post-activity accountability is good, so improvements can be made to the next project, or the next phase.

We’re told to have a A Retrospective in agile for example, and we do it… how? There’s no real process. There are a few “post-mortem” processes I’ve run across, but I don’t love them, they rely way too much on everyone agreeing to be both civil and energized, and the processes aren’t adhered to well.

I also object to the term. Even if you managed to do a terrible job, and the project is dead, your team probably isn’t. Your program isn’t. This is all an ongoing process so you need to think of it that way.

I prefer the term and the process of the After Action Report. After an activity (it’s from the US military (PDF), where you do things like shoot people in “an action”) you sit down and talk about it.

After Action Reviews are collaborative, inclusive assessments performed after any major activity or event. For business, they can be performed at the end of a phase, or any old time when there was a plan and you executed on it to some measure of completion. There’s no need to wait until the end of an entire project.

Ideally, everyone is involved, from every team on the project. Tell everyone what the process is before you start. Show them this, and make them stick to it. The moderator must interrupt people if they don’t follow the process. And the process is:

Get everyone in a room. Be ready to write things down where they can be seen, get a good moderator (preferably not from the team) and in turn discuss the:

• Plan

• Performance

• Issues

• Fixes

One person talks, everyone else listens, everything gets written down. Ideally, fewer computers are open.

Plan

Communicated by whoever was in charge of the project. This should be mostly whoever actually led, not who signed the checks. So a Product Owner or Project Manager tells us:

What did you intend to happen?

Do not talk about what actually happened. Usually, you do not even describe changes in the plan. From the original plan, describe one or more of the following:

• End state, what did you expect it to look like when done

• Operational guidelines

• Plans and coordination

• Timelines, schedules

Brief, but complete, it should not take more than about 5 minutes. If it can be done in 30 seconds, all the better. Refer to whatever documents are required, and be specific. Try not to project anything or use PowerPoint, but speak entirely.

It might be good to have higher level goals discussed as well, so you can find out if the overall business goals and strategy was met or not met. There are usually multiple level to a plan.

Write down all of this. Any method you like is good, from typing, to whiteboard to post-its.

Performance

The leadership (whoever did the Plan, and generally anyone else who could be considered a leader) does not talk.

Instead, everyone else talks. They get to answer:

What really happened?

Try to go around the table, and get everyone to provide input in turn. Make sure everyone is engaged. No asking “does anyone else have something to say” but go one by one.

Even if they say “it was said” then ask which one they would have said so that can be emphasized. It assures they feel engaged, and they might have misheard; they might have a slightly different point to make.

Analyze these results: Compare to the Plan step. Looking for deltas here, and considering it like this helps make it more brief. Improvements over the Plan are fine. Cover all changes from the plan.

Again, go step by step. Do not say why anything happened. Just what happened.

Issues

This time, everyone can talk. Many AARs open this up and everyone raises hands and gets called on, but I think that’s risky. Everyone — ideally in turn, one by one again—is answering:

Why did those things happen?

It should be strict. Why did the things that are written down from the previous phase happen. New things that happened either should be ignored, or you have to stop and write them down on the what-happened list first.

If leaders seem to be taking over, or anyone steps on someone else, it is the moderator’s job to stop it. Everyone can help keep on target

Going around the table again is probably the best way, but if everyone is getting tired of this at least make sure there is minimal back-and-forth discussion, to avoid arguments or the original point being lost in the discussion. One person talks, and the point is put up, and that’s it.

If the person bringing up the issue says they are not sure why; then go to raising hands, and one person responds at a time. Keep this under control.

Some other notes:

• You can consolidate items in the Performance step to single issues.

• Try not to bring up Issues that are not gaps in Performance.

• Discuss positive changes from plan or expectation, not just problems.

• Participants might disagree. Try to come to agreement at the end, so you can move to the next phase.

Fixes

Again, everyone talks. Same methods as above. If everyone is playing nicely, this may go towards raising hands, but I do find that people who don’t actively volunteer still have ideas and we need to drag it out of them.

Post-its are fine if it’s a big team, and then someone reads them all out loud to assure they are understood by everyone.

The core question is:

What could be done differently (Improve),

OR

What should be done the same (Sustain), in the future?

How to do this?

• Try to address each Issue in the above list. Try not to discuss Fixes for things not already discussed.

• Classify each item as “Improve” or “Sustain.” Either it was a problem to fix, or a benefit to keep.

• Note that many Sustain items are small. Doesn’t mean they aren’t beneficial.

• Everything must be actionable. Even Sustains. Assign a person (not a team, an individual). That individual must be there, and agree to it. Even if they can’t fix, they can find the person who can fix it, and it’s still their responsibility.

• Fixes should still not be personal. Even if the problem was a person, don’t use this to simply point fingers. Instead provide training, provide more communications, move them to a place or role they fit better, things like that. Everything must be actionable, and their boss more likely gets the actions, not them.

Remember in general this should not be a griping session, but sticking to the process means that issues can be brought up that might have otherwise been perceived as an attack.

You are not allowed to say “Joe wouldn’t let us do x” because you have to say “We failed to perform activity x” and then some time later, you can explain why, and very often someone else will. Many times, in my experience, the person responsible will even do it for you. “Oh, I stopped that because…” You learn there are reasons, and it’s not all incompetence and personal bias.

These often become effectively team building exercises as you learn about everyone else, and how their role really works in practice.

Take Action

This one isn’t officially part of the AAR but I think it needs to be added. After the meeting you have to make sure that the sustains and improves are acted upon.

Add a method of keeping track of the points and the assignments so when the next project kicks off things have changed, and when the next AAR notes are entered, the moderator can say “hey, this happened last time? Why didn’t you fix it yet?”

Share. Especially for sustains, summarize the results and share with the company — or if too big at least with all the PMs in this division.