If everything went according to plan, there would never be a need for rescheduling. But Murphy’s Law says that if things can go wrong, they will. Because of this, every good business owner knows the value of flexibility and that things often take longer than expected. So “extending” a schedule should be simple enough, right? Well that isn’t easy to do in situations where resources including machines, rooms and people are shared across several tasks, or when there is a sequence of events that must be followed.
In a previous blog post, I wrote about how rescheduling is the quintessential skill for schedulers. The point in that writing, was that if you can reschedule something, you can certainly build an original schedule. (I am fond of saying that scheduling is really just a special case of rescheduling.)
Here is a simple example that illustrates the complexity of rescheduling. Consider that there are 10 projects scheduled, each with five tasks that must be done a certain sequence. Assume there are eight resources that are used in different combinations to do those 50 tasks. Some of the tasks require resource #2 and #5, others require resources #3, #7, and #9, and so on. You see the problem already, don’t you? If one task runs long, then not only are its successor tasks affected, but also all the tasks that use the same resources are potentially affected because those resources may be assigned to other downstream tasks in the schedule. This creates ripple-effect rescheduling. Who wants to figure that out?
Many scheduling applications ignore this point and reschedule everything that was originally scheduled later than the over-running task. The result is maximum disruption of the schedule because rescheduling may assign resources differently. Multiply this by more than one task running late. If not totally chaotic, the operational situation is at least unstable. People are unhappy with the frequent assignment changes, and promise dates are unpredictable. Chaos!
The adage, “If it ain’t broke, don’t fix it” applies well to operational rescheduling. First, you must figure out what couldn’t possibly be ‘broke’ and therefore what you don’t need to ‘fix.’ Although the logical coupling among downstream tasks may be extensive and complicated, there is no need to scramble the schedule completely. Maximum stability can be achieved by keeping the unaffected tasks where they were on the schedule and maintaining the original resource assignments. If your scheduling application can figure this out for you, it will save you time, hassle, stress (and therefore, money) when you go to reschedule.
Finally, the same rationale applies to the tasks that finish early. (Occasionally that actually happens.) It’s clear that a good scheduling application must know the best way to reschedule while preserving as much operational stability as possible. Does yours do that?