The D•I•P•O•D Process Model – Part 2

     In Part 1, the D•I•P•O•D Process Model and template were presented and explained.  In this installment, an example deployment will be illustrated to demonstrate the variety of factors to be considered in an analysis.  Practitioners are warned against developing a false sense of security or accomplishment in a special note on troubleshooting.  Then, a number of common errors will be shared to help practitioners avoid them.

Example D•I•P•O•D Process Model Deployment
     To demonstrate use of the template, we will revisit the world of fast food, first discussed in “Lean Lessons are Everywhere.”  Specifically, the discussion of internal vs. external time focused on the production of a tray of hamburgers/cheeseburgers, a process I’ll call the Burger Bash.  The D•I•P•O•D model of the Burger Bash is shown below:

     The Burger Bash was chosen to demonstrate how a seemingly simple process can require consideration of a large number of factors, even when somewhat simplified for the convenience of presentation.  Lacking any one of the Inputs shown brings the process to a halt.  The example also demonstrates that Outputs are not always tangible and Data can take many forms.
 
A Special Note on Troubleshooting
     The D•I•P•O•D Process Model can be used to troubleshoot existing processes in two ways:
(1) A previously generated model is referenced to facilitate information-gathering and ensure proper consideration is given to all relevant factors.
(2) An ad-hoc model is generated only to coordinate short-term troubleshooting efforts.
     The first scenario is the ideal, but the second can be expected to be far more common, if the model is employed at all.  The time pressure that accompanies a breakdown provides a strong incentive to take shortcuts.  Use of the model to facilitate recovery from a failure by focusing on a narrow or incomplete process definition, a limited number of inputs, outputs, and associated data is acceptable and encouraged when circumstances call for it.  It does come with a caveat, however.
     Ad-hoc use of the model should be a signal that a thorough analysis of the process is warranted.  Too often, however, the status quo is reestablished once the crisis has passed.  Instead, the partially-developed model should be used as input to a more thorough analysis.  The analysis will be easier to complete and future crises will be less traumatic.
 
Common Errors
     The preceding discussion has alluded to some areas of concern with modelling processes according to the D•I•P•O•D Process Model, but there are several more caveats to heed.  A quick reference is provided by the following list of pitfalls to avoid:

• Failing to document and monitor all outputs
• Trying to define the process before giving sufficient consideration to outputs
• Including too many process steps in a single analysis
• Failing to document and enforce change management protocols
• Insufficient specification of inputs (grade, purity, tolerances, etc.) – do not assume that supply will be consistent over time
• Failing to monitor uncontrolled variables
• Collecting incorrect or insufficient data (inputs and outputs)
• Failing to activate the feedback loop of the Process Chain (collect, analyze, and react to data); inputs → proactive, outputs → reactive.
  
• Failing to iterate during analysis
• Failing to record the analysis for future reference and review
• Failing to consult the model once “complete” to review and update.

 
     Employing the D•I•P•O•D Process Model can help an organization effect improvements in process control, documentation, troubleshooting, and so on.  Like all models, however, conscientious efforts and attention to detail are needed to extract maximum value.
 
     If your organization needs help improving process performance characteristics through use of the D•I•P•O•D Process Model or otherwise, contact JayWink Solutions for a consultation.
 
Jody W. Phelps, MSc, PMP®, MBA
Principal Consultant
JayWink Solutions, LLC
jody@jaywink.com