Pat O'Toole's Dos and Don'ts of Process Improvement: DO Separate Process Documentation from Procedures
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
#9: DO Separate Process Documentation from Procedures
Early in the life of a new project, systems analysts are often frustrated when customers mix business requirements and implementation detail. "Tell me what the requirements are, not how to implement them" is the oft-heard chant that reflects the analysts' frustration. "Why can't customers ever distinguish between whats and hows?" is the accompanying mental lament.
A similar comment would probably be heard about the SEPG if the software personnel ever took the multi-volume set of process documentation off the shelf and tried to use it. In my last article, I suggested that you extract the training components from your process documentation; here, I'm suggesting that you further de-bulk it by extracting the procedural components as well.
Similar to business requirements, process focuses on what you are expected to do. Analogous to implementation detail, procedures describe how you are expected to do it. This distinction is often blurred because documented processes and procedures typically include many of the same elements: purpose, roles, inputs, entry criteria, activities/steps, outputs, exit criteria, etc. The real difference between processes and procedures is found in the "degrees of freedom" provided by the documented component.
For example, a Work Product Review process may have the following activities:
Prepare for the Review.
Conduct the Review Meeting.
Address the Defects and Issues.
Verify Defect and Issue Closure.
The tasks associated with "Prepare for the Review" activity may be:
Verify that the work product is ready.
Select the review team.
Assign review roles.
Plan the meeting logistics.
Invite the review members to participate.
Pre-publish the work product.
Note the lack of "implementation detail." There is no indication of how these steps should be performed. For example, the work product could be pre-published by attaching it to an e-mail, by sending it out via company mail, by walking around and dumping it on each person's chair, etc. Most likely, this process step does not warrant procedure-level instruction; process-level guidance should be sufficient.
So why am I splitting my last few hairs about the differences between process and procedures anyway?
OK, here's the punch line - CMM Level 3 is all about establishing organizational consistency at the process level, not at the procedure level. What a Level 3 organization does on each project should be consistent; how various projects execute these process steps may be vastly different. By co-mingling processes and procedures, many SEPGs encounter enormous resistance because they over-constrain their projects, sub-optimize project performance, and make Level 3 a lot harder to achieve than it needs to be.
So what do you do? Well, if you're just setting out on your process improvement journey, avoid this trap from the outset by segregating training, procedural, and process components. However, if your shelves are already bulging with a complex blend of these three ingredients, "decomplexification" is probably warranted. It may be painful to untangle this jumbled web, but it's probably a heckuva lot less painful than trying to achieve Level 3 by telling people how to do things rather than what things need to be done.
Copyright © Process Assessment, Consulting & Training 2002