The Evolution of Scheduling

If you’ve ever watched Jimmy Fallon do any of his Evolution of Dance bits, you’ll notice a couple things: We Americans started out simple, moving our bodies out of necessity with a basic step-touch, then curiously to more complex moves to accommodate more complicated beats (hello, Break Dancing), and we’ve ultimately swung back to a more simplified—albeit more “sophisticated” set of moves.

All this is a long-winded, yet very applicable way of illustrating the evolution of scheduling applications as well, believe it or not.

The construction business was the genesis of project scheduling and it’s easy to see why. To build something, you need a sequence of tasks that must be followed in order. You can’t erect walls until you have a foundation poured, and you can’t pour a foundation unless you’ve dug a hole. The logic for planning a project is dominated by the order of the tasks. When a project encounters a delay, it’s likely because one of the tasks ran over its planned time, which naturally delayed all the other tasks that followed. So, because of these order relationships in a project, the first software applications were built around these predecessor/successor relationships, formalized as “precedence networks”.

Manufacturing then took the scheduling dance in a different direction, –different moves if you will.  Because manufacturing relies heavily on machines to produce products, resources come into play–like technicians and work centers that must be assigned to get the product made. If a manufacturing process is delayed, it’s often because a machine went down or some other resource was unable to perform as planned. The emphasis on machine capacity and availability  led to scheduling approaches that focus on the assignment of tasks to machines. Analysts call this the “job shop” orientation. Tasks were queued up waiting for available machines to service them.  Queuing theory and discrete simulation were the technical approaches applied.

Yet it wasn’t long before project schedulers realized that their projects were often delayed not only because tasks took longer than anticipated, but also because they didn’t have enough equipment or people to support the tasks.   They had to add lots of “ifs” and “thens” to their software programs to accommodate these conditions. Project scheduling logic got garbled.

Similarly, as manufacturers recognized that most products had to be made using several machines or work stations in a specific sequence, they had to add sequence constraints, –or predecessor/successor relationships.  They called this the “flow shop” orientation.   And when manufacturers wanted to produce products “just-in-time”, they needed to schedule backwards just like the project schedulers did to determine  “slack-time” for an activity.

Each discipline started to find requirements common in the other’s. So, each bolted on capabilities not native to its foundation approach. The applications from each started to look like buildings with multiple additions designed by different architects. Run efficiencies went down, code became complicated and difficult to extend. Worst of all, user interfaces and terminology became clumsy and non-uniform.

(This is the part where the dance party breaks up and everyone just stands around panting and sweating not knowing what to do next.)

What was needed was a new look at scheduling that accommodated all requirements as native.  That is, we needed a new logical foundation that spanned not only project scheduling and manufacturing, but also hospitality, medical, sports and recreation–and any other sector that used scheduling to plan activities.

Scheduling went back to basic research.  I was fortunate to work with NASA to build a system from the ground up that included the simplest descriptions, and the most complex, and everything in between. NASA sponsored this research because its mission planning seemed to span the requirements from all disciplines. They recognized that scheduling needed its own discipline; it needed data structures not used in any of the separate disciplines, it needed new computing utilities like interval and profile algebra, and it needed a lexicon independent of any of the application domains. The results cut mission planning time substantially. Since then, this same approach has been applied successfully in many business sectors.

It really is a dance of sorts. The evolution of scheduling has swung from simple, to complex, to way too convoluted and cumbersome, then deconstructed and rebuilt as simple, inclusive and elegant.

So when you’re scouting scheduling applications, it really is important to look at its historical roots. Does it cater to a specific business sector or scheduling approach? That’s only fun until the music changes (ie: until your business needs evolve). Be sure any underlying architecture is robust enough to capture the requirements you’re sure to discover and you’ll be able to keep up with the latest moves with the best of them!