« Slytherin for Albus Severus? | Main | Anticipation »

from after-action to in-action review

I did the opening keynote at KM Australia this morning. A good sized audience and great feedback. They also have a meeting place where I have been settled for the day catching up on email and RSS feeds, and having lots and lots of interesting conversations. Its a good idea, a lot of people find it difficult to ask questions after a keynote, but here they join in on conversations, see that you are open to anyone and join in. Its those exchanges that are amongst the most valuable.

One of the strong points I made is that we need to move away from after-action reviews, written up as case studies. Such an approach encourages retrospective coherence, the benefits of hindsight. The resultant cases studies may impress management but they are too far down the context specific codification review to have any sustainable impact. Instead we need (or so I think) to aim for continuous capture of fragmented narrative based learning, captured as people learn, not a few days later. The access to that material is then also in-action, assembling and blending the fragments in the context of need.

Comments (9)

Simon Bristow:

Dave
I really enjoyed your presentation at KM on Monday 23rd. It was the highlight of the conference for me - just disappointed I couldn't attend your masterclass.
Do I remember you saying you were going to publish the session as a podcast? Hope so - I really want my team to listen to you speak - they'll get huge value from it.
Thanks again
Simon Bristow

Thanks Simon I plan to have the podcast and slides up next week. I will blog it as soon as its avaailable - along with the workshop presentation

Hi Dave,

After an after-action review, the goal is usually to change the processes/procedures/practices/behaviours in such a way as to improve them and institutionalise practices that are better suited to the needs of the future and avoiding problems of the past.

So it strikes me that you may be holding up your in-action reviews against a straw man - surely no-one wants to do after-action reviews just to have a bunch of case studies lying around?

In project management (e.g. PRINCE2) project leaders keep a 'lessons learned' log as they go. This is because by the time people get to the end of a substantial project, they may have forgotten the challenges they faced in the beginning stages - and so they may make the same mistakes over again in the next project they start. Keeping a log enables them to refresh their mind with the issues they faced.

It may be the goal Lauchlan but it is rarely the reality, some material may get used for process improvement, but most languishes in unused databases. Added to which the nature of recall after the event is not the same as during event. So no straw(/i> I am afraid the "man" is red in tooth and claw.

PRINCE2 is designed for highly ordered and structured development environmentsm it is inappropriate for complex or ambiguous ones - DSDM and other methods work better there (and you have given me an idea for a blog). A log kept at the time is however a good idea, and its a form of in-action review.

Well, PRINCE2 can be used to bring order to potentially highly unordered and unstructured environments in order to achieve results defined by the project mandate and business case.

But I would have thought one can't blame the tool if it is not being used properly. To get the benefits from after action reviews, we need to follow through and process and implement the recommendations. The situation is much like idea management using idea management systems (and let me mention I have just created a new blog on this at http://www.ideamanagementsystems.com) where there is a defined set of processes and activities that manage the pipeline from idea generation through to idea capture, evaluation, and commercialisation and metrics governing the whole process. Similarly with After Action reviews - we need the processes in place to process the recommendations from the Lessons Learned and monitor the success of the recommendations to complete the learning cycle.

Its also very good at achieving what in complexity is called "premature convergence". As a tool is only appropriate for those aspects of a project which are inherently ordered in nature and most user requirements for example do not fall into that box.

You establish this yourself when you talk about a "pipeline". Prince2 is a waterfall based method, DSDM, Agile etc all deal with aspects of development for which it is inappropriate.

Cory Banks:

Dave,

Congratulations on your blogging anniversary. It seems it slipped through un mentioned in your post.

I have been looking at the AAR process and have been pushing our teams to use the questioning format on a more frequent and smaller scale.

I feel the most important aspect is the sharing of the learning and we have even gone as far as to add a fifth question being "Who else could find our learning of value?" putting a little bit of responsibility on the discoverer. We also have a learning register catching fragments, not full case studies.

Now I think of it in more detail perhaps the learning log could have one or more RSS feeds that others can subscribe to and in some cases get their "Learning of the Day".

Of course the value of the learning will not be discovered until there is a need.

Congrats again and keep it up.

Cory

Hi Dave,

PRINCE2 can be used for either a Waterfall methodology or an Agile methodology.

For example, the Wikipedia article on Agile nominates PRINCE2 as an appropriate Project Management methodology - http://en.wikipedia.org/wiki/Agile_software_development

Here is a link to someone who has mapped the SCRUM agile methodology to PRINCE2 - http://www.julianonsoftware.com/public-docs/prince2-scrum-checklist.xls

There is nothing in PRINCE2 that mandates a Waterfall methodology. It's a tool and it can be used prescriptively and top down, or it can be used to manage iterative stages in an agile fashion. What it requires is specific objectives for each stage that can be validated against the project mandate and business case.

What PRINCE2 does do is impose structure. It mandates a clear project organisational hierarchy, it requires identification of stages, work packages, deliverables, etc. But when you have a complex goal to achieve, that's not a bad thing.

Anyway, I was just mentioning PRINCE2 because of the Lessons Learned aspect. PRINCE2 suggests that people need to learn from their current and past projects so that they can improve for their next ones, so Lessons Learned reviews and Lessons Learned logs are part of the methodology.

And I was mentioning Idea Pipelines and PRINCE2 Lessons Learned because both frameworks require that its not enough just to come up with ideas, defined standard processes need to be in place for those ideas to be reviewed by the appropriate people and put into action.

PRINCE2 makes that claim Lauchlan, but the level of structure imposed argues that the claim is not supported by reality. All methods suggest that learning take place, and I can agree that process improvement as a result of reflective process is useful. However it remains retrospective in nature and I stand by my earlier comments

Post a comment




Remember Me?

(you may use HTML tags for style)