Tuesday, May 10, 2011

Agile in Regulated Software - Checklists

Lets 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. Checklist also may foster an anti-change mentality and allow people to cruise through their jobs without think about them. This is why we all hate them.

Photo By: adesigna
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 their are a lot of steps to follow. It's hard to remember each step of each procedure followed. Its 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 doubly 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 are 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 less 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 documentaiton history. Thus, you must do every item on the list every time you run through a procedure. Think carefuly before adding things to a checklist.

Next up: Functional Testing vs Technical Testing

No comments:

Post a Comment