A good checklist…

  1. Breaks down complex known projects (“How do I start this huge task?")1.
  2. Shows a clear start and a clear end (has a known goal)
  3. Goes by order (first A, then B, then C. Not A and then D)
  4. Contains short steps (the law of three to four words)2
  5. is NOT time-based (a time of day, how long to do, etc.)

Here’s a good example, my “Rebound” checklist:

a checklist on a computer screen, written in Emacs. It has three checked items out of 5, and it's marked at 60%
  • Check ServiceNow (SNOW) for new Tasks
  • Check Outlook for current flags/pins
  • Check Outlook for new emails to flag
  • Check Teams' activity for chats I’ve missed
  • Check Slack

It is a complex project, and I can feel lost starting when I need to catch up with work, and I’m worried I missed something.

It does not show a clear start or end, though those are known: I start not knowing what’s going on, and by the end, I have an idea of what I missed.

Interestingly, order here is not critical, though it is implied by my priorities. Tasks in SNOW are the first to catch up with, then Outlook for flags and pins I tend to use when I can’t digest emails fully and convert them to a doable task.

Then, read emails to search for potential emails that look important and make them into tasks (or respond to emails and ask for more information to determine if there’s a task to do there and what it is.)

Then, Check Teams. People chat me, and I can miss it. Usually, when I receive a chat through Teams directly (someone is giving me a task), I create a task workflow on the spot or create it through our digital form at work (or ask them to do it so I have a record). The case here is not for that; it’s just to catch things I might have missed when I was grabbing lunch or something of the sort.

Lastly, Slack is our announcement medium for outages or similar events, though I usually get the information via Email or Teams first. It’s a good place to check to be aware if something should be made into a website announcement, a mass email, alerts, etc.

With checklists, the longer they are, in a way, the better they justify their use case. The best examples I remember are my checklists for setting up computers manually. Some of those include information that is still relevant today. At the same time though, if a checklist starts to feel tedious and I check certain items off automatically or delete them because they are not applicable, it needs to be adjusted/shortened.

Let’s talk about what checklists are not.

Checklists are not what’s going to make my day a productive one. They are a part of of my toolset, so I have to use them first. Besides, I can’t just make up stuff to use checklists for and hope to feel “productive.”

To reinforce my idea above, Checklists are not a workflow or a knowledge article. Explanations and visual aids do not belong in checklists; they belong in notes associated (and linked) to the list. Why? Because instructions make the checklist long and bloated. It’s also not a good place to find the needed information in the future. Finally, checklists are personal and should be adjusted as such, but information should be basic and accessible to others.

Because checklists are often closely associated with information and remind me of the “whys” of a certain thing, putting them at the head of an information article or a note makes sense, as long as a header or a subtitle separates them.

Footnotes

1 : This means checklists are used for known procedures. Don’t use checklists for new tasks and projects which require more exploration. The brainstorming at the start of a new project is not a checklist. However, familiar components inside a new project (for example, a packing list as part of a trip which in itself is a project) can be checklists.

2 : Checklists sum up information and may follow procedures. If explanations are needed, these should be in the notes below the list. It’s OK to have a whole workflow explained as long as the steps are clear and short in the checklist itself.