There is one essential book for anyone who wants to excel in mutual work with other people. No matter what kind of work you are in, if there are at least two people, or, ever, probably only yourselves, but started this morning on the wrong leg.

The book I mean is “The Checklist Manifesto” by Atul Gawande, American surgeon and educator.

The idea behind this book is very simple: create a set of rules and follow them to achieve success. However, the way to achieve this result generally saying is very complicated. Thanks to Atul, he managed to explain lots of complexities and bad outcomes that arise if people do not follow it.

The examples are given from the surgery, the aviation, and the construction business. We all know (I hope) how complicated can be the plans of building new building 🙂 Plenty of lines with lots of interdependencies and hard day-by-day work to keep everything on track. Everything should be planned ahead. The Internet is full of examples of such plans, e.g. https://summitreconstruction.com/2021/01/21/construction-project-plans-explained-with-example-plans/

And here is the first rhetoric question comes to my mind. Why software cannot be created like buildings? Why in 2024 we still hope that everything will be OK, that the team will deliver what is expected from them just because they are happy to work together (and, of course, they have passed multiple team building and pizza eating sessions) and create new software, and it might be not professional to ask them how much time a particular task would take? (By the way, seems the following technique to prognose the completion date of the project would work: take your team together for a week session in Alps, somewhere high in the mountains with no Internet, only initial requirements for the new project, and get them described in details and estimated line by line all the activities in the project, then save it as a WBS, and finally erase the estimates given from the brains of your team, so they cannot stick to them).

(Of course, we all know that the requirements for the construction business and software products are completely different by their nature, their agility is the key factor that prevents building software from brick and mortar:)

Personally, my understanding of a checklist was too narrow before reading this book. I perceived it as a list of checkboxes to be set after you do something; and, of course, if you haven’t done some action, then of course do, and then set. This is what the author names “DO-CONFIRM” checklist type. Another, directive type of checklists, comes from aviation, when literally for any normal or unforeseen situation a checklist with actions prescribes the exact set of actions to follow, normally in one page of text. If you combine all such checklists, you will get a typical construction plan example, or a “plan of flight”. This is the “READ-DO” checklist type.

The primary idea behind checklists is easy: people are not organized by their nature, and usually do not follow the rules even if they are obliged to follow them. “Yes” does not always mean “yes”. Citing the author, “discipline is something we have to work at”. Checklists help us to self-organize, and control others, like a nurse can check if a surgeon keeps the gloves clean after entering into the surgery room.

The second idea is to give clear guidance in critical situations, where people can easily lose their patience and make wrong decisions. To keep the brain calm, it is very important to open a guide and follow it line by line, not adding your own ideas. The book has many samples from the aviation, particularly, the “Miracle on the Hudson” case.

An interesting effect of the checklists, especially seen in aviation and surgery, is in quick building trust in the team. Giving people a chance to say something at the start likely activates their sense of participation and response and their willingness to speak up, it is a ground rule to initiate team collaboration.

Checklists are tightly related to risk management. Even if this book was not dedicated to risk management formally, it was about being ready to perform corrective actions when a risk happens, no matter whether it is a stopped plane engine or sudden blood flow during surgery. And risk actions checklist should have an exact set of steps to follow; of course, the existence of the general checklist should decrease the chances of risk to come.

So, what are my personal takeouts from this book? I have already a few formal checklists to follow in case of starting a new project or taking ownership of an ongoing project. Probably, I would add something more for day-by-day PM practices, and share all of them here.

Have a good day!