Autopsy of planning autopsies

A couple more thoughts about last week’s diagramming session, thinking about the event format.

The agenda was broadly defined, which presumably kept it attractive to a wide range of participants. Discussions were good and the diagrams produced were interesting. But two of the original ideas didn’t emerge - not a problem, but interesting to note.

• Wasn’t really about processes - with the exception of the group who looked at the placement of bike racks, the diagrams were not about process. Talking through the specifics of a process helps to pin down the opportunities to change it, especially asking the “why is that?” questions. Mostly, we stopped at the higher level - focusing on topics and associated ideas, so the diagrams were more conceptual.

• Wasn’t really an autopsy - same issue here: the idea of doing an autopsy for a previous planning process didn’t come through, though the MTA funding group got the closest. As with the process diagrams, trying to explain the steps that led to a particular outcome would show where we don’t have all the answers - potentially useful to know more about where the unknowns are.

Again, the workshop was still thought-provoking and useful. And the processes/autopsy idea was not gospel, only an idea. You can’t ask people to show up and carry out extremely constrained tasks - a lot of the fun would get squeezed out. It’s not all about process.

But maybe there’s potential to explore a slightly more structured event, something to consider if setting up a repeat session (Cambridge, looking at you).

• Up front, give some thought to why the autopsy is useful: creates use cases for future projects, highlights places where technology can play a role, makes sure we understand the scope, pinpoint ‘failure’ tipping point etc.
• Decide if there’s a specific focus: transportation funding; physical design; etc. Maybe convene a smaller group around one topic only.
• Start out with an example of a process diagram: perhaps a skeleton that the group can flesh out.
• Ask participants to draw out and explain the process.
• As a group, give feedback on the explanation: why did that happen; what is the step between X and Z?
• Fill in the gaps and reach some conclusions.
• Add the what-ifs: review the process and try out some alternative scenarios. Maybe each team passes their diagram to the next group, for some creative experimentation.

Could also borrow approaches from other fields - usability testing, interface design, disaster preparedness, forensic accounting, etc… Lots of thought has gone into looking at how and why decisions are made. Let’s re-purpose those methods.