Changeover Gantt Chart: How to Track Performance Task by Task

Why total changeover time misleads you

The most common way to measure changeover performance is to record the time between the last good part on the previous run and the first good part on the next one. That number is useful — it tells you whether you're hitting your target. But it answers the wrong question when you're trying to improve.

A 47-minute changeover that ran 47 minutes last month and 47 minutes this month looks like a flat line. But inside that 47 minutes, the mould swap took 4 minutes longer, the heat-up wait ended 6 minutes earlier, and maintenance arrived 3 minutes late. Those shifts cancelled each other out. The total didn't move. Nothing you can act on is visible.

Improving changeover efficiency requires breaking execution down to the task level — what happened, in what order, and how long each step actually took. That's what a Gantt timeline provides.

What a changeover Gantt chart shows you

A Gantt chart is a horizontal timeline. Each task gets a row. Each row shows a bar starting at the task's start time and ending at its completion time. When you lay all the tasks from a single changeover onto this chart, several things become immediately visible that a stopwatch total cannot show.

The critical path is the chain of tasks where every minute matters directly to the total. Tasks off the critical path can overrun without extending the changeover, as long as they complete before the next critical-path task needs them. Knowing which tasks are on the critical path tells you exactly where effort has the highest return.

Three bottleneck patterns to look for

Most changeover Gantt charts reveal the same recurring problems. Recognising the pattern tells you immediately what type of fix to investigate.

1. The late handoff

One role finishes their tasks. The next role starts late. On the Gantt there is a visible gap: the first bar ends, then a pause, then the second bar begins. The gap is not a slow task — it's the time between task completion and the next person starting.

This pattern is almost always a communication problem, not a skill or speed problem. The second role didn't know the first was done. They were finishing something else, or simply not watching. The fix is a clear handoff signal — something that tells the next person their window has opened.

2. The waiting task

A task that is ready to start — the prerequisite is done, the materials are present — but the assigned person hasn't started yet. On the Gantt this appears as a task bar that starts well after it could have. The resource was available; the coordination wasn't.

Waiting tasks are particularly expensive when they sit on the critical path. Every minute a waiting task delays is a minute added directly to total changeover time. The fix is usually clearer task sequencing and visible status so teams can self-coordinate rather than waiting to be told.

3. The false sequential

Tasks listed one after another in the changeover procedure, simply because that's how the instruction was written — not because they depend on each other. On the Gantt they appear as a long chain of non-overlapping bars. In reality, they could safely run at the same time.

This is the highest-value pattern to find, because it requires no faster execution — just a change in how tasks are assigned. Two tasks that together take 12 minutes when run in series take 7 minutes when run in parallel with a second person. The work is the same. The overlap recovers 5 minutes per changeover.

Related: SMED Basics: converting internal work to external explains the broader method for moving work outside the machine-stopped window.

How to build a basic changeover Gantt from your own data

You don't need specialist software to create your first changeover Gantt. You need a list of tasks and a start and end time for each one. Here's a practical approach to capturing that data and turning it into a usable chart.

Step 1 — Define the task list

Write out every step in the changeover as a numbered list. Break bundled steps apart: "clean and inspect" becomes two separate tasks. If you don't have a task list, walk the next changeover with a clipboard and write down what happens in sequence. This list is the skeleton of your Gantt.

Step 2 — Capture timestamps

Assign someone to observe and record the start and end time of each task during a live changeover. A stopwatch and a paper log is sufficient for the first run. You're looking for four data points per task: task name, who performed it, time started, time ended.

If you can't spare an observer, ask each operator to mark the time when they start and finish their assigned tasks. This introduces some rounding but is still far more useful than a single total time.

Step 3 — Plot the timeline

In a spreadsheet, set the x-axis as elapsed time in minutes from changeover start (time zero = machine stopped). For each task, draw a bar starting at its start time and ending at its end time. Group rows by role — operator rows together, maintenance rows together, quality rows together.

You now have a Gantt. Scan it for the three patterns above: gaps, sequential tasks with no dependency, and unusually long bars.

Step 4 — Identify one change to test

Pick the single highest-impact finding — usually the largest gap or the most obvious false sequential. Design one change: a revised task sequence, a handoff signal, or a second person assigned to a task. Run the next changeover with that one change and record the new timestamps. Compare the two Gantts side by side.

From one-off analysis to continuous tracking

A manual Gantt analysis is a useful diagnostic. The gap between a one-off diagnosis and a sustained improvement programme is continuous data collection — turning the Gantt from a project tool into an operating rhythm.

Why continuity matters

Changeover performance drifts. A procedure that runs cleanly this month starts accumulating informal shortcuts next month. A well-trained operator leaves and their replacement takes longer on two tasks — but no one notices because the total time only moved by three minutes. Continuous tracking catches drift before it becomes a new baseline.

Continuity also gives you trend data. The question "are we improving?" requires multiple data points. A single run-to-run comparison tells you almost nothing. Twelve runs over a quarter tells you whether a procedural change has held, whether one shift consistently outperforms another, and whether a specific line has an unresolved structural problem.

What to track on every run

• Total changeover duration — the headline number. Track against target.
• Time per task — the task-level breakdown that reveals where variation enters.
• Idle time total — the sum of all gaps in the Gantt. A falling idle time number confirms that coordination is improving.
• Critical path task durations — the tasks that directly determine total time. These are the ones to watch most closely.

The practical barrier to manual tracking

The bottleneck in manual Gantt tracking is data capture. Observing a changeover, recording timestamps, transferring them to a spreadsheet, and drawing the chart takes 30–60 minutes of work per changeover run. At high changeover frequency — multiple per shift — this becomes impractical. Teams either stop capturing or stop reviewing, and the data stops informing decisions.

This is the point at which a digital execution tool pays its way. When operators mark tasks complete on a tablet during the changeover itself, the timestamps are captured automatically. The Gantt is generated without extra work. Reviewing performance becomes a five-minute activity rather than a half-hour reconstruction.

See also: 7 Changeover Delays You Can Eliminate First — most of the delays identified there become visible on a Gantt before they're visible in the total time.

How ProChangeover helps

ProChangeover is a changeover execution platform built around the task list. Operators work through their assigned tasks on a tablet or web app, marking each step complete as they go. Every completion is timestamped automatically — no observer required, no post-run data entry.

• Automatic Gantt from every run: because task start and end times are captured during execution, a full task-level timeline is available immediately after the changeover completes.
• Critical path visibility: the platform tracks which tasks are on the critical path and flags where delays entered.
• Trend tracking across runs: compare performance across shifts, lines, and time periods without manual data aggregation.
• Live execution view: during the changeover, all roles share a single real-time status screen — reducing handoff gaps before they appear on the post-run Gantt.
• Bottleneck identification by task: recurring slow tasks are surfaced automatically, so improvement effort goes to the right place.

The result is that the diagnostic work described in this article — capturing data, drawing the Gantt, identifying patterns — happens automatically on every run, not just when someone has time to do the analysis manually.