One-Time Checklists: Planning Ahead

Have you ever done something as simple as reinstall an operating system – only to find you missed something important? What if you have to apply patches? Upgrade databases? If you forget something simple and critical…. this is definitely not something you want to do. What can we do to avoid such scenarios?

Several days ahead of time, make a checklist. Keep adding as you think of things that need to be done during the process. If it is a reinstall, do you need to copy SSH keys? Install third-party software like sudo and rsync? Reconfigure the kernel for your environment? Put all of these down on your checklist.

Break your checklist down with titles – so that you know what step you are at and so you can find it easily. For a reinstallation, you could use headings like:

  • Preparation
  • Reboot and Install
  • Postconfiguration

…and so forth.

Break the checklist down into specific tasks: an item like Configure Server is insufficient: what items need to be configured? How? Make the items specific and detailed.

Use the checklist during your maintenance, and keep notes on the sheets as you do them – and as you find things that you might have missed. Write them right on the checklist – and keep the checklist. Next time you do something similar, you can start with the original checklist.

In this way, you will miss nothing – and people who come after you will thank you profusely. Just keep the old checklists in places people can find them. A three-ring binder would be just right. Date the checklists too, put a title on them (“Reinstall of HP-UX 11i v3) and put them in some kind of order.

2 thoughts on “One-Time Checklists: Planning Ahead”

  1. Your post is spot on.

    Working in Systems Administration, this is the first thing you learn. Never, never, never do something that could take out your production systems (including your development and test systems) without a step-by-step plan (including a backout plan) in place. The plan needs to be specific enough so that I can hand it to anyone on the team, and they will have no problem understanding and executing it.

    I make my teams document exactly what they will do, and exactly how they will recover to a workable system if something goes wrong. They we review the plans prior to their execution.

    I hate to admit it, but I do like MicroSoft Project for this task (about the only MS program I actually like). It allows you to do dependancies and timing and, with practice, you can generally nail tasks down to fairly exact times. I know we’re doing a good job of planning when I execute a task and it takes nearly exactly the time the project plan specified.

    When the plans are complete, I expect to see the individual steps ticked off in MS Project, and then they get moved to a folder called “Completed project plans” for future reference.

    1. Thanks for the excellent reply!

      It’s good to hear of this used in practice. One of the things that always had bothered me about checklists in the past was that they were seen as immutable and inviolable: if you found something that wasn’t on the checklist, you were supposed to stop cold: your job was to do a checklist, not think.

      I hope this thinking has gone away; checklist are too valuable a tool to be spoiled and to valuable to be ignored.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: