The Goldilocks Parable: How Much Process is Just Right

What are the guidelines?
The Capability Maturity Model-Integrated (CMMI  ®) provides a useful—but hard to quantify—statement about process definition. The Organization Process Definition Process Area states, "These elements are described in sufficient detail that the process, when fully defined, can be consistently performed by appropriately trained and skilled people." (Emphasis mine.) In this statement, "elements" refer to process elements. This definition has utility whether you are using the CMMI for guidance or not.

 The trick is figuring out what "sufficient," "consistently," and "appropriately" mean. I have seen the best and worst of process definition, unfortunately erring on the "too much" side of "sufficient" often enough that people take the view that process improvement can be categorized into the "Big P" and "little p" camps, and that "Big P" is always bad. This article will help you to quantify the above three terms, hopefully helping to define useful improvement processes for your organization no matter what dimension is chosen.

What is a process?
Simply defined, a process is "a sequence of steps to achieve a given purpose." They are useful when they prevent us from re-inventing the wheel when starting a project. They are especially useful when many people in different parts of an organization do the same tasks. It reduces friction (wasted energy), and frees up time and brain-power for solving the tough problems rather than having to invent a presentation or documentation method for the task.

Who are the "customers" of process?
The process users are the customers of the group that develop and document processes. They can be divided into three groups: expert, average, and novice. 

• The expert user, one with many years of experience, needs brief process descriptions, templates, and checklists. Templates and checklists are valuable for preventing omission and enable consistency across multiple process executions.
• The average user may want more guidance; a process step may still be new, or not frequently used. Access to guidelines or training material is valuable.
• The novice user will want step-by-step lists of activities, thinking these will ensure correct execution of the task.

Compounding the problem of over-documenting processes is that process writers may have little background in technical writing. A novice's description contains every step in the process, including "Open template, Save as..." One has to ask, if they need to be told how to open and save files, why are they even attempting the task?

Resolving the Expert-Novice Gap
A multi-level approach to process documentation can help bridge the expert-novice gap. I divide the documentation into the following parts: 

1. The Process - a three to four page document listing that includes:
   • Inputs - things needed to start the task
   • Entry Criteria - training, events, or input attributes that must be satisfied to start
   • The Process Steps - concise description of the activity performed
   • Outputs - what is delivered
   • Exit Criteria - output attributes that must be satisfied to end the task
   • Measurements - data generated by the process that can be used to monitor and improve the process, or product developed by the process
2. The Procedure - used when a process step requires decomposition (not all do).
3. Work Instructions - step-by-step guidance when exact execution of the process is required.
4. The Template - a guide to producing the work product specified by the process, such as a requirements (e.g., the XP Story Card in Kent Beck's Extreme Programming Explained), design, or project plan document.
5. Checklists - a list of error detection and detailed content that substitutes a list for fallible memory.
6. Training - (Two suggested levels:)
   • Expert - information that allows the seasoned project manager or developer