The ABCs of Scheduling: A Return to the Basics:
Previously, in this BLOG, we have discussed the subtleties of various scheduling applications. A good app must accommodate many capabilities—some obvious, some not-so-obvious. That said, let’s review the basic capabilities that should be at the heart of any scheduling app. These are the core features that form the framework onto which detailed capabilities can be attached. Let’s take it from the top:
A: Activities should be objects of scheduling, not resources. It’s a mistake to think of scheduling resources because inevitably you will wind up looking for times when several resources are needed at the same time. Usually, activities require several different resources. And often activities require resources for only a portion of their duration. So, using a scheduling application that is designed around resource assignments can get really complicated really fast. Also, the relationships between activities and resources is one-to-many. One activity usually requires many resources. Your app must schedule activities and obligate resources as the result. Here’s a simple example: A meeting might require several people, a room and some equipment. Finding time times when all of these resources are simultaneously available is the task that a good scheduling app will do for you.
B: Bucketless time. Time “buckets” are preset intervals used by many schedulers to simplify conflict detection and to facilitate displays. For example, a calendar-based application uses day boundaries; an appointment booking application may use 15-minute intervals. These intervals become “buckets.”. If the duration of an activity must be defined as some multiple of these buckets, and must be placed on the timeline at one of these bucket boundaries, the application is limited both descriptively and functionally. Many applications with the time-bucket limitation are built that way because their underlying architecture is a spreadsheet. Each time bucket is a column in the spread sheet. But time is inherently continuous in the real world and should be modeled that way in any good scheduling application. You don’t want to schedule a 17 minute activity by rounding its duration to the nearest hour interval, or even the nearest fifteen-minute interval for that matter.
C: Constraint modeling is the third basic capability needed at the core of a good scheduling application. One of the most common limitations in many apps results from the assumption that a resource is obligated for the entire duration of an activity. However, it’s easy to see that this isn’t always the case. I suspect that these type of scheduling applications have evolved from the concept of scheduling resources instead of activities (see “A” above). More generally, an activity might need resources intermittently and in different quantities during its occurrence. To model any differently will grossly over-require resources, and produce schedules that fail maximum efficiency and output. The same rationale can be applied to the original availability model for a resource. These profiles must be time-varying, and have on-and-off times that reflect lunch hours and breaks in the work day. There are some resources that, when turned on, must be used without interruption until the requirement is satisfied. There are other resources that can be left idle when breaks occur, and activated when work resumes. Compare a baking task (not interruptible) to a polishing task (interruptible) for example.
Schedules that are accurate representations of what is possible require robust constraint modelling as a core capability. Does your app meet the ABCs?
Want to know more? Read these:
About Activities: “A” in the basics:
http://www.schedulingdoneright.com/are-you-doing-it-wrong/
About Bucketless Time: “B” in the Basics:
http://www.schedulingdoneright.com/time-is-a-continuum/
About Constraints: “C” in the Basics
http://www.schedulingdoneright.com/the-nouns-and-verbs-of-scheduling/