Keep It Simple or Face Decomplexification

A friend of mine flies all the time. Whenever he boards a plane, he sneaks a peak into the cockpit to see what the crew is up to. He says he feels a sense of comfort when he sees the captain filling out the preflight checklist. This simple act tells him that the pilot's objectives are similar to his own ”making sure this bird can

• get off the ground safely,
• fly all the way to their destination, and
• get back down ”preferably in a controlled manner.

That is, the captain fills out the preflight checklist because he/she wants to live as much as the passengers do. On the other hand, imagine how nervous my friend might be if his glance in the cockpit found the captain reading the operator's manual!

As they board, the passengers' 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 multivolume 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 project activities throughout, and ultimately delivering products to your customers, preferably in working order? Have you really committed the full process to memory so that you know the processes that you execute once every three months better than those a pilot executes three or four 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 passengers 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 preflight checklist would be if it were written such that any passenger would be able to fly a modern commercial airliner. (And imagine how quickly you would bolt from the plane if they asked the person sitting next to you to proceed to the cockpit to try!)

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 skill deficiencies, and to introduce major process changes. But it is unreal -istic 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 will be overlooked. Like the airline's preflight checklists, software process documentation should be continuously reviewed to assess its effectiveness and improved to allow better control and software quality.