The Goldilocks Parable: How Much Process is Just Right

1. • with the requisite knowledge and skill to consistently execute the work according to the organization or company practice
   • Novice - extended training for someone who has never previously done the particular activity (e.g., new project manager, new language training)

Process versus Procedure versus Work Instruction
Getting these levels of detail correct enables useful process documentation for all classes of users. The high level process lists the major steps needed to execute the task. For project planning, they might be: 

1. Develop top level work breakdown structure from requirement.
2. Estimate project size.
3. Identify work products to be developed.
4. Estimate effort.
5. Identify people needed.
6. Develop schedule.

At the procedure level, the second step might be further described in a procedure that includes: 

1. Decompose elements of the WBS.
2. Using historical data, estimate size of the piece parts.
3. Lacking historical data, use a group activity like wideband Delphi to do estimation.
4. Record assumptions and size for each estimated part.

Processes and procedures should be six to seven steps and three to four pages of text. More than that and the level of detail might be too high. Templates should provide the detailed instructions, examples, and guidelines for work product development. Checklists should list sequential steps to be performed.

Detailed work instructions are usually needed with configuration management activities, especially when tools are not used and the project or organization depends on manual control of the configuration items. It may be necessary to list the steps for ownership, modification, and return to the configuration baseline in detail. As the process becomes more automated, the details are usually handled by the tooling (a tool itself forces sequential activity, with help to guide the user).

Determining the breakpoint between process, procedure, and work instruction is somewhat like Goldilocks saying "and this porridge is just right." Trying to get this perfect in an initial release is usually not possible. When a team of users and a process person writes the process, be careful that an overly detail-oriented person doesn't take you too far in his direction. I'd also suggest interviewing the process users from the first few projects before using them, and again after several repetitions through the process. That's why change requests were invented.

Templates
A good template provides the structure for a work product. It clearly identifies instructional content and mandatory and optional content in the final product. Beware of over-zealous auditing, where minor deviations from the order or content generate corrective action requests. Leave the minor stuff to verbal comments, or for needed observations that do not require corrective action. Unused sections should have an "N/A" to indicate the author did not forget the section. If a substantial deletion is reasonable, an explanation is usually in order.

Checklists
I once heard a developer state "using checklists is unprofessional," apparently he was thinking that relying on a memory aid was somehow beneath his dignity. I consider pilots professionals, and as much time as I spend on planes I am thankful they do not have this mindset!

Good checklists are based on common errors noted in the industry for the particular activity or work product, with modifications based on your organization's experience.

Training Myths
Training will never replace experience. It only expedites the learning curve (e.g., someone that has never written a line of code versus an expert in one language moving to a different but similar language versus one moving from a procedural to an event-driven language).

Processes do not substitute for training or else you'll have a 500-pound process document.

An expert may not need detailed subject matter training, but still needs to learn how the