Before 'Z' -- A Simple Secret for Process Improvement

often it will be distributed. We are creating this plan so that we can record our initial decisions and use the plan to guide project communication in the future. Should communication need change, we will revise and redistribute the plan to the affected parties to assure that expectations are managed and agreements are clear."

The section did a pretty good job of explaining why the author was bothering to write a communication plan. It provided a good framework for the rest of the document. It oriented the reader (me in this case) to what the author was trying to accomplish and gave me a context for my comments.

The risk management plan also had a section titled something like "Purpose of this Plan" near the front that said essentially:

"This Risk Plan is intended to fulfill our obligation under organization policy section 123.a.b.c which says that a project meeting criteria X, Y and Z must have a documented risk management plan."

Although I am paraphrasing a bit, the original text was nearly this stark. It seemed that the author was not particularly pleased with the assignment to create a Risk Plan. It also was not clear that the author understood the purpose of a Risk Plan, or saw any useful reason to create one for this high-risk, mission critical project. Much of the document read like it was bits of a template that had been filled in begrudgingly, not a coherent document intending to explain how risks on the project would be identified, analyzed, and managed. As a reviewer, I had little context to provide feedback. If you don't know the author's intent, it is difficult to review for completeness and consistency.

Here's a big idea for those of you who must write policy and procedure documentation:

Take the Time to Explain Why.

A short explanation of why you bother to document a policy is useful in a variety of ways:

• Orient the author(s) to the purpose and boundaries. This can be surprisingly helpful to you as an author in terms of keeping things brief and focused.
• Help the reader. If a reader knows why a policy was created, they can begin building a model of how that intent was addressed that facilitates understanding.
• Provide a context for later review and assessment. Sometimes policies initially accomplish what they intend, but the problem or the environment changes over time. Establishing a clear context for the problem you are trying to solve helps to set a baseline for evaluation/re-evaluation if the solution or the problem don't align at some point.
• Encourage compliance. Very few people like to do things simply because they are told to do them. Explaining the whys of a policy can help reduce resistance. Don't tell people, "All code will contain comments because that is the standard." Tell them, "Because we want to facilitate later maintenance and enhancement of our system, our standard is to include meaningful comments in all code."

If you take the time to describe a compelling reason for having a standard practice, it makes it easier on the writer, reviewers, and the poor souls who have to implement the standard or comply with it. If you can't come up with a sincere justification and explanation for why you are taking the time to write something down, maybe it isn't worth doing and THAT should be addressed.