Checklist Quality is Bad Value

Kaoru Ishikawa lead the thought that said everyone was responsible for quality.  Ray Kroc founded McDonalds success on a work system of very tightly defined tasks performed by people who needed minimal training to do that job as well as their company’s expert.  Richard M Hodgetts defined check sheets (checklists) as a way to “record data on a form that readily allows interpretation of results from the form itself”.

These developments are helpful to quality: make everyone care about quality, define the job and train people, give them tools to monitor and interpret progress made on their work.  That way is the road to great management and excellent performance.

So why does it go bad?  Because the underlying reason for the checklist is lost, people complete the checklists without understanding their purpose.   Sometimes, this is simply because most people never read the documented process that the checklist was designed to work alongside: they only have the checklist.

One project I worked on had a checklist that was designed to make the team think about what they were doing at a milestone. The person who had created it had intended to help the team check was everything ready and all the quality checks were done, make sure the next steps were defined, that the risks had been considered and that actions were completed or in place for the future.

What developed was a bad checklist culture: “we have to fill out the form before we can move on or the PMO will nag us”.  The moment a form becomes bureaucracy, the battle for quality is lost: brains are not engaged and understanding has been lost.  Worst still, those checklists add effort and cost to the project without adding value: the objective is no longer quality but completion of an undervalued form.

How to avoid that?  I have advised:

• the abolition of all checklists which only have tick boxes and use of forms that collect data
• include sense checks in checklists to prompt people to check the facts (see below)
• training people to understand the risks and constraints of their role when filling out the checklist

The best way to explain a self-checking checklist is to give an example:

1. number of chapters in the book:
2. number of chapters with editor’s QA signoff:
3. number of chapters with Director’s sign off for not doing QA:
4. does answer to 2 plus answer to 3 give same total as 1? check box (Yes/No)
5. who owns actions to resolve issues highlighted by answer to 4?
6. what are the references for the documented risks (hint: at least one documented risk for each) arising from answer to 4? 
7. do answers to 5 and 6 mean the Director can still sign the release to publish the book?

But even here, we need the Director to recognise the risks taken on when signing the release, the editor must have a good understanding of what the QA sign-off means, and there needs to be a functioning risk management practice.  We are back to people understanding what their job is for, not just having the forms to do it with.

Advertisement