Pages

Wednesday, January 11, 2017

How things usually go right and occasionally go wrong


by Kent Aitken RSS / cpsrenewalFacebook / cpsrenewalLinkedIn / Kent Aitkentwitter / kentdaitkengovloop / KentAitken




The idea of failure reports has been in vogue for a few years. Engineers Without Borders is probably the best known organization that does this, and I've heard that example cited in government circles a handful of times as a model for accountability and sharing lessons learned.

What I've heard less of is how you'd write one. The last project post-mortem I was a part of was mostly HIPPO - the Highest Paid Person's Opinion - on what they'd like to see done differently the next year. Asking people to fill out templates on what they'd do differently tends to generate the obvious answers, and it has the same problem I ran into when I tried to write a personal failure report: people don't work in a vacuum, and they often don't actually know why others took the actions they did (to say nothing of organizational politics and interpersonal dynamics acting on the person holding the pen). Even the Auditor General has expressed concern that his office's recommendations to government rarely lead to sustainable improvements

I ran into Etsy's Debriefing Facilitation Guide last year, which sawed through each of those shortcomings in the first few pages.

"Most traditional accident investigations tend to focus on "Someone did not do something they should have, according to someone else." ... "this results in an obvious recommendation for the future: "Next time, do what you should." Unfortunately, this approach does not result in the safer and improved future we want."

They describe the goal state to be "the presence of people's expertise, not simply the absence of accidents," which leads the principle that the goal of the debriefing is "to discover... what [people] actually did, and how they perceived the world at the time."

At which point the document segues into principles and guides for a structured, facilitated exercise. Not simply asking people. A lot of work has to go into creating a comfortable space for discussion, and getting past surface-level answers. There's a reason the "Five Whys" is such a sticky concept in strategy and planning.

All of which takes time, particularly when a project team spans 3-5 levels of the hierarchy - as it inevitably does, though debriefs rarely honour this fact. A working-level debriefing in the absence of the people who provided guidance, direction, and governance will fall short. But, if we're talking about projects that span years, involve an array of stakeholders, or carry big price tags, systematically learning why the organization produces the outcomes it does will outweigh the costs.

"The goal of a debriefing is not to produce recommendations... The goal is to seize the opportunity for an organization to learn as much as they can, in a relatively short period of time, about how people normally perceive and perform their work. Because the people involved were doing their normal work on a normal day when the event in question happened." 

No comments:

Post a Comment