The Checklist Manifesto – the book

One of the long term goals for all of our EOS clients is to decide when and how they are going to document their core processes, necessary for scaling their business profitably. There are only 8-12 core processes for most companies. They include processes for functions like HR, Marketing, Sales, Operations (there may be a few here – documenting how you deliver your goods or services), Finance, and Customer Satisfaction.

All EOS Implementers stress to their clients that EOS doesn’t advocate documenting 100% of the business 100% completely. Rather we advocate an entrepreneurial form of documentation – document the 20% of the process that will get you 80% of the benefit. Many clients struggle with this because there are all sorts of terms out there,- processes, tasks, steps, standard operating procedures (SOP’s), operators manuals, etc. For EOS clients, the functional area, like HR, is the Core Process. Then there are steps within that Core Process. For example, in HR, the steps might be recruiting, hiring, on boarding, reviewing, rewarding and terminating. What comes next is what vexes clients. How much detail should there be in each of these steps? Should there be a task manual for each and every operation within a step? How about technical operator manuals for equipment and computer programs?

I had an aha moment about an answer to that question when I read Atul Gawande’s The Checklist Manifesto: How to Get Things Right,-

1. “Checklists (think Core Processes) are not comprehensive how-to guides”, and
2. “They are quick and simple tools aimed to buttress the skills of expert professionals”.

Gawande’s manifesto first convinces us with example after example in medicine, construction, and flying of the necessity for preventing mistakes of ineptitude – mistakes which are made where knowledge exists yet we fail to apply it correctly. For most businesses the processes to be documented are not as daunting as emergency room surgery, building 100 story skyscrapers or flying planes after engine failure, so the concept should work.

The details for each step in a core process should not be a how-to guide for a novice employee with no training in the particular function. For that, you have other detailed documentation and training. Rather, it should be a list of the expected items to be completed during quarterly or annual reviews for example. And it may reference standard forms or other detailed documentation, especially in areas where the details may change annually, like percentages for annual increases in salary.

I am not advocating a simplistic approach. One size doesn’t fit all. You need whatever level of detail you deem necessary for your business. Gawande provides lots of examples of various types of checklists, which should help you go about completing this necessary task of documenting Core Processes for your business. You can buy the book on Amazon here. I highly recommend it as context for why and how to bring peace to the documentation of your business processes.