Your feedback is appreciated ...

Documentation

Best Practices for Process Documentation: Checklists (1 of 3)

Science, with some elements of Inspiration

I’ve written before about process documentation and the need for checklists – especially for repeatable and complex processes that you may not perform every single day. A written process solves a multitude of issues:

  • Security: For complex processes with integrated platforms, a detailed list keeps you from forgetting key settings, switches, and process steps that you might forget
  • Reality: No matter how “advanced” or “highly engineered” these systems are, there is always something that must be done in just the right order, with just the right settings. Why trust your memory when you can just write the steps down?
  • Career Mobility: There is always an issue when the staff supporting a system changes. Do you have a problem employee you want to lift over the side – but can’t because they are the only person that knows the process? Do you have a baby boomer on your team, contemplating retirement? Do you find yourself or your team stuck in roles that you can’t leave, because no one else can do this job?
  • Cost Control: Are you drawn to outsourcing for the promise of cost savings, but can’t because the knowledge is not transferable? Are you stuck in an outsourcing contract with runaway costs, because the process is reinvented every time?
  • Shifting from Running the Business to Enhancing the Business: Are you forced to keep a large staff just for the care & feeding of systems, when you’d rather have those folks work on value-generating projects?

It still amazes me that even experienced techs resist creating documentation and checklists, to simplify their lives, and make their knowledge transferable. Many times, I’ve heard this resistance manifest itself as complaints:

The work we do in IT isn’t something that can be reduced to a cookbook – these are Complicated Systems, managed by Highly Trained Experts.

Click for the original …

I say they are just stonewalling – and my favorite counter-example has always been the Pilot’s Preflight Checklist. As noted in Catch Me If You Can, there used to be an aura around pilots – gifted, skilled aviators that undergo continuous training and proudly point out their thousands of hours in the cockpit. Yet, even these Highly Trained Experts rely on preflight checklists to make sure they dot all the i’s and cross all the t’s. Note that it’s not good enough to run through the checklist by memory – they actually, physically check off each step as it is completed – and no step is too small! There are just too many things that can go wrong, too many little steps that are dependent on each other.

I made this point (again) in a recent presentation, and wanted to show a picture of one of these mythical checklists. I mean, even though my dad was regular Air Force (this is probably where I got the example in the first place), I had never actually seen one of these Checklists. However, a quick Google search provided an excellent scan of an actual B-17 checklist, circa WWII.

Some of the items on the list are amazingly picayune, such as Radio – On. I also like where they call out for written documentation – the Form 1A.

Another example might be pulled from the story of Apollo 13, when the supporting ground crew had to develop a solution for fitting a square filter in a round canister. The movie dramatizes it quite nicely (note: check out this vintage movie of the filter!) – the entire rescue effort was kept on pins and needles as the engineering team was driven to create a Written Procedure! And not just because their task master was a stickler for detail  (well, he may have been) – but that’s the Best Practice!

Use these examples to continue to drive home the point that written, detailed procedures are simply the best way to manage a difficult, complicated process. And don’t get too hung up on the details – that’s what iterations are for!

Discussion

No comments for “Best Practices for Process Documentation: Checklists (1 of 3)”

Post a comment

*