Scheduling is creating a plan for the future. But how often does reality conform exactly to the plan? The original plan might offer the blueprint for an activity, but it offers little help for determining what to do when the inevitable happens.
In manufacturing or project management, corrective action is simple. Finish the job ASAP, right? But is that goal achieved by getting back onto the original plan or by creating a new plan?
The obvious strategy is to get back onto the original schedule. The other strategy is to just get to the end goal by devising a new plan starting from the new reality (or creating a Plan B). Think about the navigation system in your smart phone. If you don’t do what the voice tells you to, it either tells you to “make a U-turn” to get you back onto the route it originally planned, or it conjures a new route based on where you actually are. One is path control, and the other is retargeting.
My background is that of an optimal control system analyst. From my perspective, I think of a scheduling system as a control mechanism for a factory or project. Therefore, any deviations from Plan A can be regarded as feedback in a closed-loop control system. In other words, the shop floor or jobsite collects real time data and compares it with Plan A. The difference is an “error” that must be eliminated by corrective action. So, corrections aren’t necessarily thought of as “Plan B, C” and so forth, just adjustments or tweaks of the original Plan A.
Viewing rescheduling as a control mechanism for an operational activity suggests that path control must use spare time or “slack” to get operations back onto the original plan. Simply put: Path control is the most effective and least disruptive strategy for rescheduling when it is possible. Schedules should use slack when—and if—it’s available. If not, Plan B should kick in.
With Plan B, there should be two objectives: The first is to get as close to the end goal as possible; the second is to make the new plan as much like the original one as possible to minimize disruptions (ie: It’s better to leave an employee assigned to the same tasks that they had in the previous schedule than to reassign them every time there is a schedule change.)
Here is the big insight to take away from the control system perspective of rescheduling: Be sure your application is designed to be a good rescheduler. It must know what the previous schedule looked like to tweak in real time or build a suitable revised schedule. Simple–and stable.