Pat O'Toole's Dos and Don'ts of Process Improvement: DO Separate Process Documentation from Training Material
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
#8: DO Separate Process Documentation from Training Material
I fly all the time. Whenever I board a plane, I always sneak a peak into the cockpit to see what the crew is up to. I feel a sense of comfort when I spot the captain filling out the preflight checklist. This simple act tells me that the pilot's objectives are similar to mine – let's make sure this bird can:
Get off the ground safely;
Fly all the way to our destination; and
Get back down – preferably in a controlled manner.
That is, the captain fills out the preflight checklist because s/he wants to live as much as I do.
On the other hand, I would get very nervous if my glance in the cockpit found the captain reading the Operator's Manual! As I board my flight, my working assumption is that the pilot knows how to fly the plane. The pilot simply uses the preflight checklist to ensure that the plane is fit for use, and to lower the probability that critical safety precautions are inadvertently overlooked.
So why is it that your organization's multi-volume set of software process documentation gets less use than a preflight checklist? Are you not working on important projects that would make internal headlines if they "crashed and burned?" Is the project team not entrusted with planning the project at the outset, performing their project activities throughout, and ultimately delivering products to your customers, preferably in working order? Have you really committed the full process to memory such that you know the processes that you execute better than the processes a pilot executes 3 or 4 times a day?
One reason that process documentation remains on the shelf is that its authors have a different working assumption about project personnel than I have about pilots. Authors of such documentation typically assume that the project personnel do not know how to plan, manage, or fulfill their project responsibilities.
But let's face facts, when the process was written your people probably didn't have all the requisite skills to perform their project responsibilities using the newly defined process. So naturally the documentation was written to fulfill this need. However, just imagine how thick the pre-flight checklist would be if it were written such that any passenger should be able to fly a modern commercial airliner. (And imagine how quickly I would bolt from the plane if they asked the person sitting next to me to proceed to the cockpit!)
Lack of skills is a transient issue that should be addressed by training. Your organization should provide ample skill-building interventions to train novices, to address specific skill deficiencies, or to introduce major process changes. But it is unrealistic to expect experienced project personnel to need or use the same detailed instructions required by the novice. Is it any surprise, then, that your process documentation remains on the shelf unopened if 90% of its bulk is dedicated to such mundane tasks?
So, differentiate between training material and process documentation. For students, training material is typically a single-use asset – they use it in the classroom and then stick it on the shelf. In contrast, process documentation should serve as a ready reference guide for the process executor. Like a preflight checklist, it should focus on the vital process elements that lower the probability that critical steps are inadvertently overlooked. When it comes to process documentation, think thin to win. Give experienced project personnel the equivalent of a preflight checklist and watch them fly!
Copyright © Process Assessment, Consulting & Training 2002