Why Checklists Fail
Part 1: A Framework for Documentation That Improves Operations Instead of Creating Busywork
Problem #1: We Don’t Know Why We Use Checklists
A superintendent I worked with had a radical and valid point: “Why do we need checklists? If we just looked at the drawings, we wouldn’t need checklists.” Why do we need a separate document to tell teams to look at the drawings, or to inform them of something they should already know?
When I was working in design and construction quality, one of our initiatives was simplifying our quality control checklists and making them more effective. I was determined to cut out unnecessary items to streamline them for our project teams and save them time. However, I ran into a huge problem: We couldn’t simplify anything. As I dug into the first checklist and discussed it with our steering committee, we kept asking ourselves:
“Why is this item on here? What are we trying to prevent?”
The conversation became more philosophical: “Why do we use checklists in the first place?” I realized we couldn’t simplify our checklists because as a company, we couldn’t agree on why we needed them. Some thought they were to be used as teaching tools. Others suggested as reference guides. Others wanted to ensure accountability. To track that their teams checked the work.
This problem isn’t unique to construction. A hospital system implements surgical checklists because they were instructed to do so. (Atul Gawande documents this phenomenon in his book, The Checklist Manifesto: How to Get Things Right.) A software team uses deployment checklists because “that’s what DevOps does.” A restaurant has opening and closing checklists because the corporate office mandated them. When we think about why, we hear:
“To prevent mistakes.”
“For quality.”
“It’s policy.”
The Solution: Establish a Company Philosophy on Checklists
Before you can have effective checklists, you need to answer these questions for your own organization:
Why does your company use them? Are you trying to achieve zero rework? Error-free execution? Prevent safety incidents? Ensure consistent customer experience? You need to be specific. “Improve quality” is not specific enough.
Who uses checklists? Is it everyone? Just new employees? Specific roles? In construction, we often think checklists are for field teams. But what about estimators? Designers? Project managers? In a hospital, is it just surgical teams, or do admissions, pharmacy, and discharge all need checklists?
Who should create them? This is critical. Is it a corporate function creating checklists for everyone? Or do teams create their own? I’ll argue later that this distinction determines whether your checklists will be used or ignored.
When should they be used? Before work starts? During execution? After completion? Most companies use checklists only for inspection after the work is done. That’s too late. (See Part 3 for more on this.)
How many should be used? Should you have 50 checklists? 500? What determines if something deserves its own checklist versus being a line item in another checklist?
What type of checklists are utilized? Are they inspection tools? Communication guides? Training materials? Decision aids? The answer to this question fundamentally changes how you design and use them.
These questions can serve as a framework to create a culture that allows checklists to be successful.
Here’s what this looks like in practice when there’s a clear philosophy on checklists (or other element of business documentation):
A manufacturing plant says: “We use checklists to prevent the three failure modes that cause 80% of our warranty claims. Every checklist must tie back to preventing these failures. If an item on a checklist doesn’t prevent one of these three things, it shouldn’t be on the checklist.”
A software company says: “Checklists are communication tools, not compliance documents. They exist to ensure all stakeholders have discussed critical decisions before deployment. If a checklist item doesn’t require a conversation, it should be automated instead.”
A restaurant group says: “Checklists ensure consistent guest experience across locations. Every item must be something a guest would notice if done incorrectly. If it’s invisible to guests, it goes in a different system.”
Notice the specificity, how each philosophy immediately tells you what belongs on a checklist and what doesn’t.
Without a clear company philosophy, here’s what happens:
Teams complete checklists for compliance, not because they are useful. “I filled it out, so I’m covered” becomes the goal instead of preventing problems.
Checklists become bloated. Every time something goes wrong, someone adds an item to a checklist. Over time, they become unwieldy documents that take longer to complete than the actual work.
Utilization drops. When checklists are too long or unclear in purpose, people stop using them. Then management adds more enforcement, which creates resentment, which decreases quality of completion, which defeats the entire purpose.
“Corporate” and “operations” work against each other. Corporate teams try to create one-size-fits-all checklists. Operations teams complain they don’t work for their specific situation. Both are right, and both are wrong, because nobody has agreed on what checklists are supposed to accomplish.
How to Start
If you’re a leader responsible for operational execution - whether you’re a COO, plant manager, director of operations, or project executive - this is your job. You can’t delegate defining what checklists mean in your organization to a quality department or training function. Start by gathering your leadership team and honestly answering those six questions above. Don’t move forward until you have clarity.
Once you have that philosophy, everything else becomes easier. The next three problems with checklists - and their solutions - all depend on having this foundation in place.
In the next post, we’ll tackle Problem #2: Checklists are not organized strategically within operations, which makes them nearly impossible to manage effectively.