Because systems change, you should periodically review the "big picture" context for your important checklists.
"Mail Server Configuration Data." Check.
"User Security Settings." Check.
"Scalpel." Check. "Wait - what?"
Atul Gawande points out in his book, The Checklist Manifesto, that checklists save lives and improve outcomes in hospitals. Checklists help surgeons verify that critical tasks are complete.
IT people use checklists to complete action items as quickly and efficiently as possible, as well. The value of a checklist is the same in both fields: to identify and verify actions taken. In IT - at least in most cases - there's less blood spilled and lives aren't at stake.
In past months, the Google in the Enterprise column alone has featured several checklists: "The first five steps Google Apps administrators should take" by Scott Matteson, along with my own "Manage staff transition in Google Apps: a 10 step checklist", and "Checklist: Setting up a user with Google Apps and Chrome". (Google joins in the fun, as well, by publishing their own "Deployment Checklists and Forms". Need a checklist for an IT task? I'm confident one exists.)
IT checklists work well, as long as systems remain the same. Unfortunately, software-as-a-service evolves rapidly, resulting in IT checklists becoming outdated quickly. In early 2013, Google rolled out changes to Google Apps and Google Forms and users received new collaboration features and improved editing capabilities. Google enhanced the power of the "Create" button in Google Drive so users can quickly launch third-party apps with a click. And in late 2012, Google launched a new compose and reply experience in Gmail. Checklists and documentation need to be reviewed every time features change.
Shared IT checklists help people properly configure rapidly changing online tools.
Because systems change, you should periodically review the "big picture" context for your important checklists. (Yes, you should look at each of the checklist items. That's easy.) The "big picture" here means a check of people, processes, and tools. If tools have changed - features modified, added or removed - you'll need to update your checklist. If user needs or behavior has changed, you may need to update your checklist. If you identify a repetitive process with many steps, you might save time and improve outcomes by creating a checklist of the process tasks. Finally, as more people use your checklist, you may need to expand your checklist to include additional tasks.
Borrowing an idea from Wikipedia, you even might let other people edit your checklists. This can help keep your checklists up-to-date. You might simply publish your checklist as a Google Doc or Spreadsheet and give anyone on the web permission to edit your document. More likely, you'd want to restrict access to your checklist to people within your organization, or specific people on your team. You might also want to limit people to commenting on your document, not editing it. This lets you retain editorial control: you can review comments and modify the checklist as needed.
To manage my checklists, I've used both Google Docs and Checkvist. Most often, I use a Google Spreadsheet checklist when I help small organizations adopt Google Apps. I've put the spreadsheet online so you can see it -- and edit it. I also maintain a list of system setup tasks intended for non-technical users. I used Checkvist.com to create this non-editable list. Checkvist offers both a free and Pro version ($38/year per user). Checkvist may be used to create shared, editable lists, as well.
I use checklists to streamline and simplify tasks I repeat often: conducting technology assessments, setting up new systems, and configuring Google Apps. I find it gratifying to complete a checklist.
So this week I can mark off "write article about checklists." Check.