What costs do you introduce by solving problems sequentially?
By MARK RIFFEY for the Flathead Beacon
This week I traveled to Kyiv, Ukraine for meetings with a software team. The meetings went well and I will be on my way home by the time you read this, however I had some travel issues.
While this is not a travel column, it is worth noting that all of the issues I encountered were either created or they were problems that are not allowed to solve themselves because the people and systems communicate with each other at a level that forces them to work in a linear fashion.
It prompts questions we should consider for ourselves and our clients.
What do I mean when I say “Work linear instead of parallel”? Some examples from my trip provide a good illustration of linear vs parallel.
When my plane from Missoula left Salt Lake City (SLC), it left late because the de-icing line in SLC was long. I don’t know if they had a de-icing truck out for repairs, or if they simply didn’t allocate enough trucks or drivers, or if something else was going on.
Regardless of the reason, the situation and the possible lack of fallback solutions (ie: backup trucks, drivers on call, etc) created delayed flights for many that day – creating a linear problem.
If the normal pace of takeoffs cannot be maintained, then SLC becomes a bottleneck in the West and flights to surrounding cities start struggling with schedules as a result.
This cascades into many linear problems at once since every city with a late flight potentially has stranded passengers or passengers with missed connections. Old news, but it’s important to consider how quickly this can cascade.
When my plane left Missoula, it did not de-ice. I don’t know what the protocol is for de-icing, but about 15-20 minutes into the flight, we had failed to continue our climb to cruising altitude and started to turn back. The flaps would not retract and this wasted too much fuel. Unfortunately, we were above maximum landing weight, so we circled for 20-30 minutes to burn off enough fuel to land.
The irony is that this circling was burning the same fuel and time we would have burned if we had simply continued to SLC with the flaps down, normally a 54 minute flight.
This quickly ate into the layover I had built in.
When we got to SLC, we were unable to pull into our gate right away. By the time I got to the gate for Paris, the plane door was closed and I could not board.
Five minutes matters
The big thing that hit me during this process was seeing multiple instances of seemingly insignificant two to five minute delays cascading into hours of delays. Any one of them could have been planned out of the airline’s response and it would have allowed enough time for three people on the Missoula flight make the connection to Paris, much less all the other people who were missing connections that afternoon.
The thought to consider is this: How many two to five minute delays are built in to what you do, how you serve, how you deliver, etc? How do these affect the client’s outcome? What costs do they increase when service fails? What costs will the client incur?
What happens when a few of these five minute delays push your delivery of products or services to the next business day?
What systems do you have in place to automatically tend to conditions that can create these delays?
Every business encounters problems. How businesses react to them and what they do to eliminate / prevent situations that are controllable is critical.
How does automated, perhaps parallel problem solving save money?
- What’s the circling fuel expense to get below max landing weight vs. the cost to continue to SLC?
- What’s the cost of lost seat revenue for the empty seats and hotel stays for interrupted travel?
- How much delay is introduced at the gate when you don’t automatically rebook travelers?
- On a daily basis, what does a five minute gate wait cost, in missed connections, lost seat revenue and hotels?
Look at your business. Make a list of preventable delays. Knock off one at at time.