Checklists are very simple tools that can have a huge impact on IT efficiency and effectiveness. Here's how to use them.
Checklists offer many benefits. It's a great tool for facilitating efficiency and effectiveness. Situations where checklists should become your tools of choice include:
- You have an infrequent but repeatable process or opportunity that causes the IT team to react.
- You have a complex system for which you want to carve out level 1 triage options.
- You have a temporary exception process that needs to be adhered to until a more permanent solution is developed and deployed.
When I worked for a horse racing company in Louisville, KY, the company owned four to six race tracks. Racing "meets," as they're called, only last for several weeks each year. Sometimes they have two "meets." But each time, the track has to re-open to the public.
Food vendors, marketing kiosks, digital signage, racing office computers, temporary employee computers and all of the new and the unknown need to be set up and deployed. The goal of the checklist was to document all of the common elements, understand the lead times on each element and build a standard project plan with resource allocation, budget, and time frames all ready to go.
We were trying to accomplish two primary things. Unhappy internal customers and a huge increase in help desk tickets during every meet opening. The demands on IT during a meet go up anyway with project work. On top of a ton of regular help desk tickets, there is an enormous constraint on resources. These constraints caused us to miss most of our Service Level Agreements.
The results were unhappy customers and a burnt-out IT staff. Our PMO took on the job of developing the checklist. We looked at all of the common elements and standardized items like computer lead times, time-clock setup, etc. Then we looked at the elements that were unique to each track and attempted to facilitate changing the local process in favor of a standardized (and usually cheaper) process. We also documented the unique requirements that we could not standardize.
To address all the new processes that tend to pop up, we looked for a source. Nine out of ten new processes introduced to a track meet came from marketing. So we set up pre-meet meetings with marketing. The first was 60 days out from opening to document new programs and then again at 20 days and 15 days out. There were always some last minute changes, but the pre-planning allowed us to not get too constrained regarding resources. The result was a significant drop in help desk tickets and much happier customers.
My new company is a long-term care company that plans on acquiring another 100 health campuses as quickly as possible. I'm planning the acquisition checklist for this company. On the IT side, a checklist does exist, but will need to be refined. The IT group is centralized supporting 6,000+ employees. The idea is to come up with a standardized network management, systems management, and telecommunications package that can be dropped into place with minimal on-site implementation and support required.
The main reason for this is to get the new campus up and running and fully integrated within the shortest possible time period. At the same time, I want to make the process scalable from an IT perspective. Instead of having to bring new acquisitions on in a linear fashion, we need to design a way to do multiple locations in parallel. We want to take the integration time down from weeks to a matter of days. This includes training on new systems and standardized processes.
Our second reason for a checklist is that we want to take some complex system and carve out processes for use in a help desk so the specialized resources supporting those systems can focus on more value-added tasks. If the help desk gets a call for telephone support, the support tech pulls up a telecommunication checklist. This helps the tech learn a new system and protect the system from "learning" mistakes.
Basically the checklist consists of common problems that have a prescribed process for troubleshooting and solving before having to escalate them to a level 2. The troubleshooting steps are clear and require limited system access, but represent the majority of user issues with that system. Basically, checklists in this instance allow your $15 per hour resources to solve low-level problems before they get to the more experienced admin you're paying $45 per hour.
Third, SMBs are rife with exception processes for dealing with system limitations, process limitations, and so on. Establishing these checklists should be a direct result of identifying, designing, and budgeting for the optimal solution and then coming up with an interim process to follow until the optimal solution comes on line. Having the checklist gives you something physical to point to that is a priority to eliminate.
For example, let's look at an HR process for on-boarding new employees before a new HRIS system is deployed. The HRIS system would send alerts for terminations, new employees, and promotions with a workflow that would confirm completed steps. In the meantime, a process where an e-mail is sent to the help desk with a particular subject kicks off the use of a checklist for that process. These are typically used for compliance purposes, but it also helps to prevent some detail from being overlooked.
I'm a big fan of keeping things simple and the checklist is a very simple tool that can have a huge impact on IT efficiency and effectiveness.