So we might have some idea on how to improve our skills and knowledge, but it still takes 20 minutes to find a specific switch in the cabinet, the last time a server lost a fan we didn’t find out until after it overheated, and we have no idea how many licenses we have purchased. And we’ll figure it all out right after I finish this next help desk ticket.

This is the second article in a three part series on major gaps that we never seem to have the time to address as well as ideas on how to overcome and initiate processes for closing or reducing those gaps. Each article is based on one high-level subject and provides ideas on how to gain individual and group level traction.

[Coding|Provisioning|Reporting|…] Standards

It’s always easy to put off little tasks until later. Labeling new equipment, updating a diagram of a wiring cabinet or server rack, creating monitors for performance and temperatures, testing your backups. Ok, some of these are less than small, and yet we continue to put them off.

Take a moment and list two or three items you would like to make part of your process for deploying new code, new servers, new databases, new (whatever you do all day long). Ok, now open up your calendar and look forward to the next month, two months, 6 months…where is the reminder that your going to start doing that task, that your going to go back and do it for all the work you have completed to date? Yeah, thought so. This isn’t a “one day” task, it’s a “Never would have done it” task. Remember, I’ve been there too.

Step 1: Make a Standard

The first step is to write it down. Creating a ‘standard’ is going to be difficult, we naturally shy away from writing these things down because writing is powerful and once it’s written down we feel committed. On the other hand, we want it to get done, so that power that makes us nervous is also going to help strengthen our self-discipline and get it done.

Keep your standard as simple as possible. The more complex your standard is, the harder it will be to actually go out and follow it. if you later find items that need to be added, you can add them, but make do your best to keep it simple and to only add things that are actually practical (both in doing and in result). A simple standard is easier to follow and takes less time, letting you build good habits with less effort.

For instance, if this is a server deployment standard, list the standard set of software that has to be installed on every server, the standard settings that have to be changed, the services that have to be enabled, an item to ensure it is added to the backup schedule, and one or two of the items you pretended to list earlier when I asked (like monitoring).

After building your simple standard you should have a list of X things you already do plus one or two you always thought you should do or, when it broke, wished you had done. Save that document and each time you go to execute the task print off a copy and use it as a checklist.

Step 2: Revise your Standard, Review your Process

Next add a recurring appointment (once a month or once a quarter) to your calendar to spend 15 minutes reviewing your standard. During this scheduled time you will first assess how well you are following the standard. If there are lines you are skipping then try to root cause the issue and figure out why you are skipping them. If you end up back at “there is never time for..” then go back and review the reasoning for why you wanted to do it in the first place. If a 5 minute task for each server is going to prevent outages and millions in losses, it’s going to be a little harder to make a case for not doing it.

After reviewing how well your doing each line, remove any lines you have determined were wasteful or are no longer necessary and add some additional items to the list. Again, keep your standard in a list format so you can easily use it as a check list to make sure your following your standard process, but also make sure there is enough description that a co-worker would be able to duplicate your process.

Step 3: Do It

Make it happen. You have a written standard and if you need further help staying on the straight and narrow then here are some more ideas:

Tell Your Boss

You have a reason you’ve created this process and your boss probably remembers the last time it cost time, money, or resources to solve a problem that could have been sidestepped. If you can convince them of the importance of your standard then they will also provide some extra [incentive|[pressure|etc] in making sure you follow it.

Tell Your Co-Workers

They’re going to think your crazy, so again you will need to remind them how x minutes of work is going to save the group from that issue that happened in the middle of the night back when. If the group will be sharing responsibility then you not only want to share the standard with them, you probably want to include them in it’s inception. You don’t have to have everyone in a room together, but you can get them to agree it’s a good idea and offer to build s starter standard that can be revised later. Remember, keep it simple so you can build good habits, later on the group can argue for a 50-page list of items.

Hold Yourself Responsible

Add an [annual|quarterly|whatever] goal to deliver the results of the process. Take the overall issue your trying to resolve (time involved in finding switches during outages, potential costs if a server fan goes out, cost to fix a code defect after it has been deployed, etc) and create a goal that says you will reduce that issue and will do so by implementing and following a standard. A good businessy goal is something your department can report directly up the chain and should be listed on your achievements for year-end review. Worst case, if you find a previously unknown issue that prevents you from reaching the goal, you can still claim success in making savings as well as uncovering a potential dangerous and unknown issue that the department can now work on resolving.

Discipline

To many of us it probably sounds crazy to voluntarily create a standard and make more work for ourselves, but it’s the greater path of laziness. If we can convince ourselves to have the discipline to identify and execute those little tasks, it will mean fewer 3AM phone calls, fewer stress-filled outages, and fewer year-end inventories audits and other time consuming (and sometimes painful) activities. When you start looking at the number of risks and the amount of unplanned events you can avoid, suddenly the extra 10 or 20 minutes every few weeks, months, or years doesn’t seem like so big a deal. But you have to do it, each and every time. Half the job is usually not going to net you half the results, so be disciplined enough to do it every time. If part of a task has to be put off due to an emergency deployment, schedule a meeting reminder to finish it later that day. If your a heavy procrastinator, like me, then remind yourself constantly than it is lazier to do that 5 minute task now then to take a 4AM call. Make it happen.

Next – Part 3

There is never time to sit and reflect on how your job gets done, experiment to find better ways, or attend non-technical training to improve your team or processes. In fact, if only you could reduce the time you spend on such-and-such task, you might finally have the time to focus on that. Hmm, chicken and egg.

Miss an article in the series?

There Is Never Time For … Part 1: Training and Development

There Is Never Time For … Part 2: Standard Processes

There Is Never Time For … Part 3: Process Improvement