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.
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.