For Rob: The Checklist Manifesto

My friend Rob suggested that I read The Checklist Manifesto. I did so. He then asked me questions about it, which I answer here:

What field were you looking to apply TCM to? Any examples of problems you hoped it would apply to?

I went into it with no real idea what it was about. All I had was your strong recommendation, based some of our conversations about (I believe) Made To Stick.

Do you think there's a meaningful difference between cockpit checklists and construction checklists?  Do you think this needed more exploration?

I'm undecided. Certainly what he found useful about them was different. In the case of construction checklists, he emphasized the communication component (the submittal schedule) rather than the "this is what you do" component (which is probably some variant on a Gantt chart). In the case of cockpit checklists, he emphasized the latter, which makes sense given the number of people involved.

One complaint I've heard is that it gives too little guidance on how to actually make a list.  Once that was called out I realized I was filling in gaps with my GTD knowledge, so I am not sure about this one way or another.  Your thoughts?

It certainly lives up to its "manifesto" claim in that regard: It presents a clear call for action, without really giving specific guidelines about how to it. That's not entirely true, as there's a few choice paragraphs in the "The Checklist Factory" chapter about what makes good and bad checklists. But there are too few concrete examples. Did you notice how the whole book is about the development of the WHO Safe Surgical Checklist, but the checklist itself is never included in the book? (If you're interested, it's here.) I certainly would have like to see examples of each of the types of checklists that he talks about it. He also talks about the need to test and refine new checklists; I would like to have seen before and after versions.

Do you think this idea has any real chance of penetrating the geek mindset?

I do think there are real challenges to adoption, as he identifies in "The Hero In The Age Of Checklists." As to whether those are overcome, your guess is as good as mine on that.

Now that you're done, how do you see yourself applying this?

Any book like this is like the cave in The Empire Strikes Back for me: What's in there is what I take with me. What I took with me was a lot of stuff about Scrum, since that's what I'm living in right now. There's a lot of resonance there: pushing authority out the people on the ground, insisting on regular communication to resolve problems, and following a checklist-like process to take care of the dumb stuff so that you can be smart. Plus, the inspect-and-adapt cycle of Scrum lends itself to the development of checklists. We'd already started to create checklists for the different types of stories we implement; I'm working on one now for estimation.

Beyond that, I see some potential for application in RPG design. As you pointed out, the end-of-session and end-of-year processes in Mouse Guard are basically checklists of this. They get you to stop and think about the right things, which ultimately is what the manifesto want you to do.

Does that answer your questions?

Comments

[Rob Donoghue]

Good answers, though I will totally be bugging you at Origins about Sooper Sekrit Question #6.

Also, Switch is awesome.

[Paul]

I just read the Kindle sample for Switch. It's either second or third on my reading list now.

[Fred Hicks]

Does it really need to penetrate the geek mindset as what it is? All you need is a small number of geeks whose minds it DOES penetrate, making use of it in products consumed by other geeks. The Mouse Guard checklists are an example of one potential vector.