The exercise was simple. A batter would lob a ball really high into the air and the fielder would have to catch the high ball, immediately throw it back accurately towards the batter who would knock it along the ground. The fielder would then catch the low ball and return it to the batter who would lob another high ball for the next fielder in the line.
Simple straightforward and practical.
The problem came when one of the fielders didn't catch the ball. It threw the rythmn of the practice and the guys would have to regroup and start again.
I got to thinking how this applies to process.
At first glance it’s a simple process with a number of moving parts (or steps). The process is designed so that each step can be executed in a sequence and the output of one step is used as the input of another. The problem comes when the output of one step is not what is expected by the following step. This is the case with the cricket practice. The batter was expecting a ball to come at him from the previous fielder so he could launch that to the next participant in the process. When the ball didn’t come back (because the fielder dropped it) it made the process grind to a halt.
In reality that solution is really simple: Have a second ball ready to throw into the process when the previous step fails to deliver. But this is what a lot of process definitions steps fail to take into account. They are designed to run with an optimum process flow (i.e. they assume that the output from previous steps is valid). Designing some error handling into a process is always easier than trying to fix a process when it doesn’t work as designed.
How many error processing steps do you have in your processes?
Photo Credit: siddharthkhajuria via Compfight cc
The Perfect Process Project Second Edition' is now available. Don't miss the chance to get this valuable insight into how to make business processes work for you. Click this link and follow the instructions to get this book.
All information is Copyright (C) G Comerford
See related info below