Beware of Stovepipe Scheduling

A doctor’s office schedules appointments for their physicians using an application built specifically for medical practices, but they find out that there aren’t enough examining rooms to support that schedule.

• A baking plant makes products in batches that must be finished once they are started. They use a foodservice scheduling software that accommodates that requirement, but also assumes that all tasks such as oven cleaning and repair must also be finished once started. In reality those latter tasks can be interrupted overnight and continued the following day. Logically, people-based resources are being wasted if they are not scheduled that way.
• A recreational sports management organization schedules the games and their fields using an application built specifically for the needs of sports scheduling. They discover, however, that several coaches manage multiple teams and their application doesn’t identify the potential conflicts. They need to schedule umpires as well, and the scheduling application isn’t designed for that.
• A printing plant has long runs on presses that need paper changes every 90 minutes but can otherwise run unattended. They use a scheduler built specifically for printing applications but assumes that people are assigned to tasks for the entire duration of those tasks. It’s clear to see that doing it that way wastes the time of their staff and ultimately makes their entire printing business less competitive.

These are examples of how using scheduling tools that are built for specific industries fail to accommodate the inevitable peculiarities of any operation. I call these “stovepipe” applications because they are limited by their designer’s narrow view of the requirements for that industry. So how many real scheduling situations fit exactly into one of these stovepipes? Most find the limitations of these domain-oriented applications sooner or later.

Consider this:

• Does a word processor assume that it will be used only to write screen plays? What about novels?
• Does a spread sheet application assume that it will be used only for building budgets? Do you need a different application to build a cash flow projection?
• Does a presentation builder assume that the only capabilities needed are to support the pie charts used for a sales presentation?

Obviously, these office tools have been built around requirements that are domain-independent. That is, their designers and developers have recognized the capabilities needed by multiple users in multiple industries, in multiple applications ranging from the home user to the CEO and built a stovepipe-free application to accommodate those flexibilities.

Scheduling as a domain-independent discipline in its own right has been studied for years by operations researchers, mathematicians, computer scientists and management scientists. They have contributed proofs that the problems are indeed Complex. But solution techniques that work for practical situations have been limited to special cases. Those special cases are the stovepipes in the theoretical world.

So we now have stovepipes for business applications and other stovepipes for theoretical applications–which is pretty ridiculous. In the 1990’s and early 2000’s some work was done to remove the business stovepipes and to find scheduling approaches that would work anywhere and could be customized to any application. Those approaches have matured and now belong in the office product suites just like word processors, spreadsheets, and presentation software.

Because these generalized approaches remove the limitations frequently found in the stovepipe schedulers, they are worth looking at as an alternative. It’s time to graduate to the next level, don’t you think?