When Will the Work Really Happen? Downtime-Aware vs. Elapsed-Time Schedules

The plant runs in shifts, closes for holidays, stops for planned maintenance, and loses hours to breakdowns. The wall clock never pauses; the calendar does. Every schedule answers one question: when will this work really happen? The answer depends on whether the schedule models capacity at all.

Planners live with the mismatch daily. The plan says done Friday; the plant says Tuesday next week. That gap is what happens when work is planned on an uninterrupted clock and lands in a plant that does not run that way. Two kinds of schedule give two kinds of answer. One subtracts downtime and non-working windows from capacity before computing timing. The other lays durations on a continuous clock and lets the gaps show up later, if at all.

When the plan treats the clock as capacity

Elapsed-time planning is a practice, not a product: job durations placed on a continuous clock, typically in a spreadsheet or on a whiteboard maintained by the planning team. The calendar reasoning is not missing: the planners hold it and apply it by hand. What is missing is a model that enforces it. The spreadsheet does not subtract an outage from capacity, because it holds no capacity to subtract from, so the check happens in someone's head or not at all.

An elapsed-time plan handles the outage in recognizable shapes. The calendar slides: durations stay fixed and are re-applied after the gap, so the outage never appears as lost capacity. The wall clock stretches: the end date is pushed out by the raw outage duration, and every later job inherits the slip. Or the week is rebuilt by hand, which absorbs the planning team's hours because there is no quick way to see what the outage did downstream. Each is reasonable without a capacity model. The failure is the absence of the model, not the people maintaining the spreadsheet.

The wider evidence runs the same direction. In planning studies, people systematically under-predict completion times: fewer than half of participants in the demonstration studies finished by the date they had predicted themselves. That bias is directional, and it is why a continuous clock runs ahead of reality. Field audits of working spreadsheets also find formula errors in a large majority of them. That is a reason not to trust the arithmetic either way, rather than an explanation of the same one-way gap.

Subtract the outage before you schedule, not after

The fix sounds like arithmetic, but it is a matter of where the arithmetic happens. Working capacity should be reduced by the outage, holiday, or non-working window first, and timing computed in what remains. That is the subtract-before pattern, and it is what capacity-modeled scheduling does.

The arithmetic differs because the problems differ. An operation interrupted by an outage does not simply resume where it left off: the interruption can push the remaining work across a shift boundary, and the penalty can exceed the outage's own duration. Adding the outage at the end treats timing as if capacity were unaffected. Subtracting it first routes the work into what is genuinely left.

flowchart LR
    O["A job spans an outage window"] --> E["Elapsed-time plan<br/>outage added after timing"]
    O --> C["Capacity model<br/>outage subtracted before timing"]
    E --> P1["Finish-time claim<br/>overstates how early work finishes"]
    C --> P2["Finish-time claim<br/>shows when work really happens"]

The same outage reaches two kinds of plan and produces two different finish-time claims.

What keeps capacity-aware timing honest

Each mechanism below carries one piece of what "honest timing" means. Together they are a model that matches the plant's calendar.

Subtract before scheduling. Downtime windows, holidays, and non-working windows are carved out of working capacity before the schedule computes timing. Work is routed around the outage into the hours that remain, rather than given an end date that ignores it.

Machine processing advances by working minutes. An operation that cannot finish before a shift ends resumes when the next shift opens. The schedule records both the time actually worked and the total span it took; the difference between them is the non-working time the schedule absorbed.

Holds between stages run on the wall clock, on purpose. A cure, dry, cool or quality hold is not machine work, and the chemistry does not stop for the weekend: a 48-hour hold spans 48 hours of calendar whatever the shift pattern. The model tracks two clocks and knows which one each duration belongs to. The distinction matters: "elapsed time" is the wrong basis for machine work and the right one for a hold.

The schedule and the visual tell the same story. Outages and holidays render as shaded bands on the schedule chart, and an operation that spans a shift boundary appears as separate working segments. Gaps are shown, not hidden, because timing and rendering come from the same calendar-and-downtime data. The planner sees why a bar pauses.

A wait-material pause is visible. When a stage runs out of material before the next supply arrives, the schedule shows that pause between the processing bars instead of folding the idle time invisibly into one long bar. The pause is bounded to supply starvation inside the schedule: the idle is named and attributable.

The objective is computed on the calendar's terms. The scheduling algorithm's objective (total production time, when the last job finishes) is evaluated through the same calendar- and downtime-aware model that renders the chart. The number the algorithm works toward is on the same terms the planner sees.

When an outage lands. The planner records the outage window and re-runs the schedule; the recomputed schedule's timing already excludes the lost hours. This is a planner action: the system does not detect a breakdown or revise the schedule by itself. In Auto mode, a re-run recomputes the production sequence; in Semi-Auto mode, the planner's sequence is preserved and timing is recomputed around it.

Maintenance, in one line. Planned maintenance is entered as a downtime window and subtracted like any other outage. No condition monitoring, no sensor data, no derived windows. The planner decides when the window falls and enters it.

What an outage really costs, in hours

An elapsed-time plan treats an outage as additive: add the hours, shift the end date. It therefore understates how much capacity the outage consumes. And the lost hours go beyond the outage itself: breakdowns, setups, micro-stops and speed losses all subtract real working time that no plan built on a fixed processing rate sees (this one included).

The numbers vary by plant, and they stay attached to the plants they measure. On one beverage bottling line, overall equipment effectiveness (the share of scheduled production time that turns into good output) averaged 69.35%. Pure breakdown accounted for 0.89% of that scheduled time, while reduced speed was the dominant loss at about 28.5%. Read that as what it is, capacity lost on one line, not as a verdict on how wrong any plan was.

The unit of an outage is hours lost and share of capacity.

What to look for in a schedule

When you evaluate a schedule, your own or a vendor's, ask three questions. Were outages subtracted from working capacity before timing was computed? Does the chart show the gaps, or hide them? Does the recorded working time count working minutes?

No schedule guarantees against a disruption no one has entered yet. The claim is narrower and stronger. Timing computed on the modeled capacity is trustworthy to that extent, and an elapsed-time plan overstates finish times relative to that same capacity story. That is the difference between a schedule that says Friday and one the plant can believe.