Designing by checklist

This week I've seen several different reviews both in the UK and the US, and listened to the HBR Idea Cast on the new book, The Checklist Manifesto, by Dr. Atul Gawande, surgeon at Brigham and Women's Hospital.

His 'big idea' is that using safety checklists in the operating theatre saves lives while "a study backed by the WHO in eight hospitals, … found that implementing the list has cut major complications in surgery by 36% on average". It doesn't seem that revelatory to discover that checklists work – isn't it the same technique used in TQM and continuous improvement approaches to reduce errors? The book I wrote about recently 'Quality is Personal' uses the concepts of checklists to keep things on track, and airline pilots have been using them for years. (Charles Lindbergh was one of the earliest users in 1927).

Most of the commentators are impressed by the simplicity of the idea of checklists, and the results using them gets which is not surprising since they have a long history of working effectively. Only one reviewer that I came across (the Economist's) was skeptical – not of the approach but of the idea of taking a whole book to present the notion. His (or her?) review states that "The Checklist Manifesto" started out as a New Yorker article. A magazine article is how it should have remained. Even as a short book it is bloated and repetitive".

I use checklists quite a lot myself – I have one for packing, one for shopping, one for work routines, etc. and find them very helpful. But the current surge of interest in the Checklist Manifesto led to me wondering whether I should be revisiting my use of them in organization design and development work? Again in this arena I frequently use them, but I think there may be opportunities for me to be more formal and consistent in their application.

One that worked very well was with a client who, at the end of each stage in the project, conducted a "Go, No-Go Review" which was a seven part checklist based approach to deciding whether everything was in place to proceed to the next stage of the project: for example, "Part 5 Performance Reporting: Demonstrate readiness of reporting systems" had the following questions:

Go, No-go Criteria review questions

  • Is the reporting timetable in place?
  • Is the reporting process included in the competence training program for the operational team?
  • Are the operating processes and work instructions in place that enable the report to be generated by the operational team?
  • Does the system generate automatically all required reports under test circumstances that provide all the details required by the company's reporting processes and procedures?
  • Is there a contingency plan in place to deliver a report on time in the event that the automated system fails?

Each question had to be answered (and signed off) by the teams involved in developing the performance reporting system. This approach did work to keep people on track, highlighting areas for further work, and stopping continuance of the project before resolution of outstanding items.

The value of the checklists in team working situations is that using it as a basis for discussion (and not just as a thoughtless tick-box exercise) to check that everyone knows what's going on and what is needed to proceed seems to iron out hierarchies, and allows involvement, increased understanding, and better decisions to be made by each and all of the team members.