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.
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:
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
JayWink Solutions, LLC
If you'd like to contribute to this blog, please email firstname.lastname@example.org with your suggestions.
© JayWink Solutions, LLC