It’s not always a race to the finish line. For manufacturing, the goal is to produce an order on time–but not too early. Why?
Finishing early creates an inventory that has to be stored and it creates an expense for supplies that need to be purchased before they’re truly necessary. Early finishes also tie up the production resources, which renders them less available to take on new, high-priority demand. Some say that loading a production schedule too early also decreases flexibility to accommodate contingencies. That’s why the ideal situation is always to manufacture on time–but not too early. Supply chain specialists call it “just-in-time” scheduling.
Project scheduling is similar. Managers who plan and execute projects like construction have always known that determining the exact time required to accomplish a task within a project is an iffy, best-guess scenario. Therefore, they usually build in contingency time to buffer against the uncertainty. To do this effectively though, they need to know which tasks will–if delayed–add time to the end result. These tasks are on the “critical path.”
However, adding contingency time to a task that is not on the critical path accomplishes nothing because there is already slack that allows delay without affecting the end date for the project. Because of this, project schedulers schedule forward to get an earliest end date, and then backwards to get the latest end date. In the process they determine the slack for each task. The buzzwords for this type of scheduling are “CPM” (Critical Path Method) and “PERT” (Project Evaluation and Review Technique).
Like manufacturing, project scheduling is heavily dependent on the precedence network which specifies the order in which tasks must be performed. Because of the prevalence of predecessor/successor relationships among the tasks, it is tempting to think about scheduling the earliest first in forward scheduling and the latest first in backward scheduling—but there is a subtle trap in this thinking, of course.
To satisfy the predecessor relationships, it’s only necessary that when the schedule is completed, all predecessors are on the timeline earlier than their successors. However, it is not necessary that the scheduling logic process each task in precedence order.
That’s an important distinction.
Here’s an example: Suppose you are planning a construction project and a particular task can only be scheduled on a specific Thursday because that’s the only time the subcontractor is available. When planning the project, you would place that task on the timeline first, and then schedule its predecessors to occur before that Thursday. The processing sequence should be to schedule the Thursday task first, then schedule the other tasks around it. Note that the processing sequence is different from the precedence order.
You could easily construct a similar example for backward scheduling.
It’s important to recognize that a scheduling application should have flexibility to schedule both forward and backward as well, right? And it should have the ability to use a processing sequence that is more general than earliest task first or latest task first—obviously.
Sometimes it’s not so obvious—and that’s okay. If your scheduling application isn’t up for the job, you’re probably spending a lot of time revising its output. Time to upgrade your app.