\uap> \uah1>When Process Documents Are Not Useful \uap>When writing a procedure often the author does not understand how to properly document the steps. Rather than simply telling someone HOW to perform the process, the author instead documents a set of requirements that people must meet. A procedure written in this manner allows people to perform the procedure in multiple ways. The conventional wisdom that states that commands and directives tell an individual HOW to perform a process is misleading. Instead, commands and directives communicate WHAT an individual should do. \uap>A procedure is a set of step-by-step instructions that explain how to perform an activity or task. To be useful and repeatable, it is better to write each step so that anyone who follows the instructions can perform the task the same way. Specifically, procedures include the following: \uaul> \uaSequence of activities
\uaInspections and reviews
\uaGuidelines and standards used
\ua/ul> \uap>In order to aid the acceptance and consistent use of its procedures, the organization should produce a set of useful assets. These assets support a fundamental change in behavior, as project teams no longer need to create processes from scratch. Instead, project teams use the organization’s standard procedures. The objective is to define the procedure so that it can be performed consistently across projects, but allow enough flexibility to meet the unique requirements of each project. \uah1>Consequences \uap>By not specifying how to perform the process steps, the author is allowing anyone that performs the process to use any method he or she chooses. \uap>The challenge facing process authors is to document the process such that it is neither too detailed nor too general to follow. If the procedure is too detailed, then the authors have painted themselves into a corner, as the process may be impossible to follow. On the other hand, if the procedure is too general, then the user can basically do anything he or she wants. \uap>Here is an example of a typical, but incorrectly worded, procedure step. \uaul> \uaThe Project Manager derives estimates for the size of the software work products.
\ua/ul> \uap>On the surface, this statement sounds reasonable until you try to perform this step. The ambiguous wording of this sentence rapidly does not tell you how to derive an estimate. Since there are many different methods and practices for deriving estimates, each time someone performs this step a different method could be used, resulting in different outcomes, thus crippling an organization’s ability to analyze its process and identify process improvements. \uap>During a conversation the Project Manager might state that he or she derives estimates by using the project requirements and historical data to determine size estimates. The Project Manager then reviews the size estimates with the Team Leads for reasonableness. This level of detail is sufficient to document a procedure that has a greater likelihood of being consistently understood and followed. \uah1>Call to Action \uap>As it can take a considerable amount of effort (time, money, and staff) to document the processes, procedures, and process assets, executives want to be assured that their investment brings value to the company. Of course there are other actions you can take to address these issues. But the points above have proven critical over the years ensuring consistent use of the company’s processes. \uap>Talk to us about how your organization could benefit from our innovative advice, delivery, and capability improvement services. See more information at: www.PPQC.net
\uah1>About the Author \uap>Henry Schneider
is the owner and principal consultant for PPQC, a small elite, highly specialized consulting company that rapidly delivers analysis and tailors solutions to maximize an organization’s earning potential. We help companies strike the balance between people, process, and tools by leveraging extensive experience across more than a dozen industry sectors.