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.
The importance of separating the "what" and the "how"By lucasnevant, Jul 13, 2005 10:10 AM I completely agree with the author's point of view. It extremely important (and not always easy) to keep the "what" and the "how" separated.The procedure must be designed by analysing how well it contributes to the process goal, and needs to be flexible to include detailed best practices identified in process execution by participants.
The process definition is more stable and normally changes are responsibility of process owners (normally business managers).
