Thursday, January 6, 2011

After you are done, you are not done

I keep running across people (as with this Agile training I am in) who think some sort of post-activity accountability is good, so improvements can be made. And they do it... how? No real process. There are a few "post-mortem" processes I've run across, but I don't love them, and they 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 like the "After Action Report" process. After an activity (it's from the US military, where you shoot people in "an action") you sit down and talk about it. After Action Reviews are collaborative, inclusive assessments performed after a major activity or event. They can be performed at the end of a phase, etc. instead of waiting till 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. Which is:


  • What did you intend to happen?
  • End state, operational guidelines, timelines, everything else you need. Brief, but complete. Might take a couple minutes. For field exercises, maps and so on can be broken out. Use whatever documents are required, and be specific.
  • Should be given by whoever was in charge of the project, or currently is. Probably the PM.


  • What really happened?
  • The leadership (whoever did the Plan, and generally anyone else who could be considered a leader) does not talk. Or, if there are a lot of them and the input would be good at this phase, does not talk first.
  • Try to go around the table, and get everyone to provide input. Make sure to engage. Even if they say "it was said" then ask which one they would have said. It assures they feel engaged, and they might have misheard; they might have a slightly different point to make.
  • 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 deltas.
  • Do not say why anything happened. Just what happened.


  • Why did those things happen?
  • Everyone can talk. If leaders seem to be taking over, or anyone steps on someone else, stop it. One person talks, and the point is put up, and that's it. Minimal or no discussion, except 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.
  • You can consolidate items in the Performance step to single issues.
  • Try not to bring up Issues that are not gaps in Performance.
  • Again, discuss positive changes.
  • Participants might disagree. Try to come to agreement, so you can move to the next phase.


  • What could be done differently, and what the same, in the future?
  • 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."
  • Note that many Sustain items are small,; the point is to expand them to larger states sometimes.
  • Fixes should still not be personal; don't take people off projects, but provide training, provide more communications, things like that.
  • 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.
  • Ideally, arrange to follow up. Some method of keeping track of these 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?"
Even for informal reviews (conducted as needed, even after something as simple as a meeting) there must be a facilitator. Ideally, this person is uninvolved. At the least, they should not contribute themselves, except as a research moderator might in our other jobs; they may lead and incite conversation, but should not promote their own ideas. Everything must be written down. Preferably, where everyone can see it. It is possible to 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…" Not a terrible summary of the process: There are many bad summaries. Don't be too annoyed if google is not that helpful.

No comments: