Best Practices for Process Documentation: Iterations (2 of 3)

Last time, I wrote about checklists , and showed the example of the B-17 preflight . Simple, fits on a single page, and hits all the critical steps, in just the right amount of detail. Plenty of processes in the IT department are made That Much Better if they are accompanied by detailed, effective Process Documentation.
 
Of course, that's all motherhood and apple pie - everyone agrees that the existing checklists are great. But how do you get started? I mean, assuming you can get the techs to agree to create documentation - how do you keep them motivated when they realize that the finished documentation will probably run to over 100 steps on multiple pages?
 
There's a really simple trick to make process documentation easy - and we'll steal it from the Agile Development teams. Time box your process documentation task; for example, you could schedule 1-2 hours before the work starts to develop some documentation (create or add to existing). Then get your work done ... and plan on another hour or two afterwards, making updates based on what you just experienced. Don't spend more than an hour or two - document what you can, then stop and get the work done.  
 
You won't be finished, of course - but that's the beauty of electronic documentation and iterative development. The first step of any process is always  "make updates to the existing documentation". You only have to start with a blank sheet of paper once - the first time. Each time you go through the process, you update the documentation - it will only get better.

• A very complex, step-by-step procedure gets a bit more detailed with each iteration
• Examples, exceptions, and critical dependencies get called out after you "get bit" - and you never make the same mistake twice
• Lessons learned at the end may shift around the order of events - improving quality, speed, and minimizing downstream freak shows
  

After the first few iterations, you may find your changes, additions, improvements are getting pickier - but that's okay. I've never seen a set of process instructions that couldn't be improved somehow ...

• Add checkboxes, page numbers, and space for follow up notes. Make the printed directions a working tool, a piece of paper that helps capture new learnings and process changes for next time.
• Add a spot to capture start/stop time or durations. Build up a history of time data - this makes it easier to estimate ETA, scheduling the event, lining up resources, etc.
• Rework the process document to function better on your corporate intranet - eliminate the need to print and distribute.
• When vendors introduce new versions of software, new features to implement, you'll be ready to incorporate those changes into your documen.

The key is to never think of the document as Finished. Don't fall into the trap of skipping the Process Review step, before AND after you perform the tasks. Once you stop, it will be hard to get back into the habit; process entropy sets in, and before you know it, you are back where you started - undocumented, out-of-control processes.