A really interesting article from Saturday's Times, by Matthew Parris
http://www.timesonline.co.uk/tol/comment/columnists/matthew_parris/article5679226.ece
He bases his article on thoughts brought on by a squeaking door at Derby railway station, which has remained unfixed for months. He suggests that this sort of persistent low-level problem is seldom the subject of review, even though that fact that it persists is probably symptomatic of some major cultural or systematic flaws within the station-management organisation. He notes that official reviews tend to be either theoretical and highlevel, or a reaction to a major disaster (often accompanied by blame-seeking). He proposes that review of "a real, small, unsensational fault whose folly no one would dispute" such as a squeaky door that remains unoiled, is a powerful way to unravel the fundamental problems in an organisation.
Why is this important? Because if an organisation can fail to notice, or fail to fix, a squeaky door, then maybe something else has remained unnoticed or unfixed. Something with far bigger consequences.
It strikes me that this is exactly what Knowledge Management can help fix, and by this I don't mean those aspects of Knowledge Management related to creating databases, or even those aspects related to creating communities. I mean the nitty gritty of regular learning reviews, such as the After Action reviews of military or oil-drilling activities, or the Retrospects that are built into projects.
When I facilitate these learning reviews, the most valuable question is Why*? You start by asking - Why is the door squeaking? Then you keep asking Why (as per the Toyota 5 Whys http://software.isixsigma.com/library/content/c020610a.asp) until you get to the real root cause of why the squeaky door has been ignored for months. You can imagine the sort of conversation -
Why is the door squeaking?
- Because nobody oiled it
Why did nobody oil it?
- Because they did not feel it was their job
Why did they not feel it was their job?
- Because a) it was not in their job description, or b) they had no job description, and c) nobody does anything that is not in their job description, or (etc etc etc)
Why does nobody do things that aren't in their job description?
- Because (and, by now we might be getting into more fundamental issues such as positive and negative incentives, fear of transgression, lack of vision, lack of ownership; I dont know what they would be in the case of Derby Railway station)
Local actions can be taken to fix the squeak, but higher level actions will need to be taken to fix the problems that allowed the squeak to continue unfixed. If these actions lie at the level of the individual station, then learnings for other railway stations can be identified and shared, and actions taken across the railway system
But this leaves me with a question for AAR facilitators. What do you do with these higher level actions? Especially at team After Action review (AAR) level? In most of the AARs I have worked with, the actions remain with the team. Does anyone have experience of how to escalate the more systemic problems, in order that actions can be taken (probably at a much higher level in the organisation to fix them?
*Why, as in the third question of the AAR - why is there a difference between aspiration and reality
Monday 9 February 2009
Subscribe to:
Post Comments (Atom)
Posts
2 comments:
I have spent the last 2 or so years facilitating LLRs (Large scale project AARs) and the last 12 months working on exactely the question you pose. What I came up with was a system by which lessons are categorised as local(owned by the team leader/project manager), functional (owned at a functional or capability level) and business (owned by the business). As you say most of the lessons are in the former group and these have a clear owner. So do the second group as long as the communication to them works. The third is the hardest to do but is in no way impossible.
The route that I use to greatest success is through business assurance and business process owners. Some of the people in those areas will tell you until they're blue in the face that everything in the world can be solved with a working process so I let them prove it. The lessons get taken to the process owners who decide if there is a process change, re-communication or whatever and if so the actions get tracked as part of a business scorecard which is a contract deliverable.
At least in this way the lessons get recorded in a system that exists within standard business practice and should, in theory, be acted upon.
There are other things that can be done like a regular review between the LLR co-ordinator and the board on the key recurring issues.
Hi Knowledge Gamer and thanks for your comments! Nice blog.
I agree completely when it comes to large scale reviews, and in BP, in the large scale project reviews, we identify federal and local lessons.
I guess where I was looking for experience is the case where something big, turns up in a very smale scale review, such as a platoon-scale AAR, or an AAR conducted on a task. There, i think the escalation process may be less clear.
Post a Comment