Published on April 25, 2011

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

Let’s be honest: Checklists aren’t the most exciting topic to blog about. However, in the context of regulation, they become interesting. Everybody loves checklists and hates them at the same time. It’s really easy to make them and just as easy to forget to use them. Later on, after the emergency and/or reason they were created has subsided, using the checklists becomes a ceremony – something that must be done rather than a helpful tool. The checklist also may foster an anti-change mentality and allow people to cruise through their jobs without thinking about them. This is why we all hate them.

All feelings about checklist aside: If each detail of your project’s history is going to be scrutinized, checklists are essential. On a regulated project, there are a lot of steps to follow. It’s hard to remember each step of each procedure followed. It;s really easy to finish delivering a feature then forget to check the software verification report in to your document management system. Once this occurs it looks like you didn’t test the feature before checking it in. Worse, you moved on to the next step of features and never turned in the verification report ever. 9 months later an auditor finds it and you have to double prove you did the testing and that you didn’t miss any other steps someplace else. Nobody wants to be in a position where they are on the defense. Often a missed step means all of the testing and tracking is nullified.

There is a number of things you can do to ensure you have good lists and they get used often.

  • Make them short – A 10-page checklist is not going to be used properly or use up time at the cost of efficiency. Train your staff. Don’t rely on process to get quality work.
  • Have fewer steps – Can you tighten up your process and simplify it?
  • Create checklist by role rather than at stage gates – The list will be shorter and highly focused on what matters to the person doing the work.
  • Have the team members create their own checklists – They can identify the handful of tasks that are at risk of getting missed. That’s your checklist!
  • Review checklists often for new procedures and question why each step exists often.

Finally, keep in mind that whatever you put on the checklist becomes part of your project documentation history. Thus, you must do every item on the list every time you run through a procedure. Think carefully before adding things to a checklist.