Guide · 2026-09-27

How to Show Delays in an MS Project Gantt Chart: 5 Steps

A project can look healthy until a key task slips, pushes its successor, and quietly moves the finish date. If your Gantt chart shows planned bars without clearly exposing late work, stakeholders may miss the warning signs.

That creates awkward status meetings. You have to explain which tasks are late, how far they slipped, and whether the delay affects the final milestone. Manually marking every bar can also create a chart that becomes outdated after the next schedule update.

But here’s the truth: Microsoft Project already includes the views and fields you need. Set a baseline, enter actual progress, choose a status date, and use the Tracking Gantt view to reveal schedule variance. The five steps below show exactly how to do it.

How to Show Delays in an MS Project Gantt Chart

To show delays in Microsoft Project, save a baseline, record actual task progress, set the status date, open Tracking Gantt, and compare planned dates with actual or forecast dates. Delayed tasks appear through variance fields, progress bars, and visual differences between baseline and current schedule bars.

  1. Save a Baseline Before Work Begins

    A baseline preserves the original plan, including task start dates, finish dates, durations, and costs. You need this comparison point before you can measure schedule slippage clearly.

    To save one, follow these steps:

    • Open the Project tab.
    • Select Set Baseline.
    • Choose Set Baseline again.
    • Keep Baseline selected.
    • Choose Entire Project unless you only want to preserve selected tasks.
    • Select OK.

    For example, suppose a testing task was planned to finish on June 10. If the task later moves to June 14, the baseline remains on June 10, making the four-day delay visible.

    Here’s why: without a baseline, Project can show the current schedule, but it has no original plan to use for comparison.

  2. Enter Actual Progress and Revised Dates

    Project cannot display a reliable delay until the schedule reflects what really happened. Update task progress regularly instead of changing dates alone.

    For each active task, review these fields:

    • % Complete shows how much work has finished.
    • Actual Start records when work began.
    • Actual Finish records when work ended.
    • Remaining Duration estimates the work still required.
    • Finish shows the current forecast completion date.

    You can update a task by selecting it and entering a percentage in the % Complete field. For more control, open the task details and enter actual dates or remaining duration.

    Imagine a five-day design task that should be 60 percent complete by Friday. If it is only 20 percent complete, Project can recalculate the expected finish date and reveal the growing variance.

  3. Set the Status Date

    The status date tells Project where actual progress should be measured. It acts like a reporting cutoff for your schedule.

    To set it:

    • Open the Project tab.
    • Select Status Date.
    • Enter the date used for your progress review.
    • Select OK.

    For a weekly review, you might set the status date to Friday, June 7. Project can then distinguish completed work, current work, and work that should have started or finished by that point.

    Let me explain: a status date prevents progress from becoming vague. If your team reports every Friday but the schedule still uses an old cutoff, delay indicators may describe last week instead of the current situation.

  4. Open the Tracking Gantt View

    The Tracking Gantt view is the quickest way to show planned work beside the current schedule. It displays baseline bars and current task bars together.

    To open it:

    • Select the View tab.
    • Choose Tracking Gantt from the task views.

    In this view, the baseline bar represents the approved plan. The current bar represents the latest schedule. When the current bar extends beyond the baseline bar, the task has moved later than planned.

    A task planned for June 10 but forecast for June 14 will show its current bar extending four days beyond the original baseline position. That visual gap gives you an immediate explanation during a status meeting.

    You might be wondering: what if the chart is too crowded? Hide unnecessary columns, widen the timescale, or apply a filter for late tasks. A clean view makes the delay easier to interpret.

  5. Display Variance Fields and Highlight Late Tasks

    Bars show the story visually, while variance fields provide the exact numbers. Add the relevant columns to your task table.

    Right-click a column heading and add fields such as:

    • Baseline Start
    • Baseline Finish
    • Start Variance
    • Finish Variance
    • Duration Variance
    • Total Slack

    A positive finish variance usually means the current finish is later than the baseline finish. For example, a seven-day finish variance means the task is forecast to finish seven days later than planned.

    You can also highlight late tasks with a filter or custom bar style. Use a filter that shows tasks where Finish Variance is greater than zero, then apply a noticeable bar color through the Format tab.

    The best part? You can combine the visual bar comparison with numerical variance. The chart shows where the delay occurs, and the table explains how large it is.

How Project Calculates and Displays Schedule Delay

Project compares the current schedule with the saved baseline. A delay appears when a current start or finish date occurs later than the corresponding baseline date.

For example, consider this simple schedule:

Task Baseline Finish Current Finish Finish Variance
Requirements review June 5 June 7 2 days
Interface design June 12 June 16 4 days
User testing June 19 June 25 6 days

The testing task has the largest finish variance. However, that does not automatically mean the project finish will move by six days. Slack, dependencies, calendars, and parallel work can absorb part of the delay.

Here’s why: a task can finish late while the project milestone stays on schedule if it has available slack. A task on the critical path usually deserves faster attention because its delay can move the final completion date.

Use the Critical field or critical path formatting to identify tasks with little or no total slack. Then examine whether a late task controls a key milestone.

Ways to Make Delays Easier to Read

Use a Consistent Status Routine

Update progress on a fixed schedule, such as every Friday afternoon. A consistent routine makes one reporting period comparable with the next.

Ask each task owner three practical questions:

Those answers help you update percentages, actual dates, and remaining duration with less guesswork.

Separate Current Forecasts from Original Commitments

Changing a task finish date changes the current forecast. It does not change the original commitment when a baseline is already saved.

Keep both views visible. The current schedule tells you what may happen, while the baseline shows what the team originally expected. Removing the baseline after a delay erases the comparison you need for learning and accountability.

Use Milestones for Executive Reporting

Senior stakeholders often need a concise view. Add milestone tasks for releases, approvals, handoffs, and major inspections.

Then show each milestone’s baseline finish, current finish, and finish variance. A milestone moving from September 12 to September 19 communicates risk faster than a long task list.

Check Dependencies Before Assigning Blame

A late task may be waiting for another activity, approval, resource, or external handoff. Review predecessor and successor relationships before deciding on corrective action.

For example, a development task may appear late because a design review finished three days behind schedule. Moving the development date alone will not resolve the dependency.

Common Reasons Delays Do Not Appear Correctly

Delay reporting can look wrong when the baseline is missing or when actual progress has not been entered. Project then has limited information for comparing planned work with current performance.

Another common issue involves manually typing dates. If you enter a later finish without updating progress or remaining duration, the schedule may not represent the work accurately.

Calendars can also create confusion. A five-day delay on a calendar with weekends and holidays may span more than five calendar days. Review working time, exceptions, and task calendars before interpreting the result.

Finally, check whether you are viewing the correct baseline. Project supports multiple baseline sets, and a team may accidentally compare the current schedule with an outdated baseline.

How to Present Delays in a Status Meeting

Start with the affected milestone, then trace the delay to the tasks that drive it. This keeps the discussion focused on consequences rather than every late activity.

A useful status view includes:

For example, you might say, “The release milestone moved four days because integration testing started late. The team will add a second tester and review progress on Wednesday.”

That statement connects the delay, its cause, its effect, and the next action. A chart becomes much more useful when it supports a decision instead of merely displaying a warning.

Natural Project Delay Tracking Solution: ONES.com

ONES.com is a unified platform for project management and knowledge management, powered by ONES Assistant. ONES Project handles project planning, tracking, workflows, and reporting, while ONES Wiki supports team knowledge management. You can purchase them separately.

ONES.com product screenshot

Value Proposition

If your team needs clearer delay visibility across projects, ONES Project provides Jira-compatible workflows, reporting, custom fields, sprint management, and automation in one project management environment.

Core Capabilities

Application Scenarios

Software release planning: A product team can connect development, testing, approval, and release tasks. When testing slips, reporting can show the affected milestone and the work still required before launch.

Regulated or restricted environments: A team operating on an air-gapped network can use a self-hosted deployment while maintaining controlled access to project plans, status updates, and workflow records.

Cross-functional delivery: Marketing, engineering, and operations teams can use custom workflows and shared reporting to coordinate handoffs. A delayed approval becomes visible before it blocks the next team.

Common Challenges When Showing Schedule Delays

Challenge: No Baseline Exists

Problem: The current schedule has changed several times, so nobody knows what the original commitment was.

Solution: Save a baseline after the plan receives approval. If the scope changes significantly, preserve the original baseline and create a separate approved comparison when appropriate.

Challenge: Progress Updates Are Inconsistent

Problem: Some task owners enter percentages, while others only move finish dates. The chart then mixes different reporting methods.

Solution: Establish one update routine. Define how your team records actual starts, actual finishes, remaining duration, and incomplete work.

Challenge: Late Tasks Are Not Affecting the Finish Date

Problem: A task shows a positive variance, but the final milestone remains unchanged.

Solution: Check total slack and task dependencies. The delayed task may have spare time, or another activity may control the project finish.

Challenge: The Gantt Chart Is Too Crowded

Problem: Baseline bars, current bars, milestones, labels, and many columns make the schedule difficult to read.

Solution: Create separate views for detailed planning and executive reporting. Keep only the fields needed for the audience reviewing the chart.

Challenge: Revised Dates Hide the Original Plan

Problem: Team members overwrite planned dates and lose the history of the commitment.

Solution: Protect the comparison by saving a baseline before making schedule updates. Treat the baseline as a reference for performance reviews.

FAQs

Which Microsoft Project view shows delays most clearly?

The Tracking Gantt view usually provides the clearest visual comparison. It places baseline bars behind current task bars, so you can see when work has moved later. Add Finish Variance and Total Slack columns for exact figures and risk context. If the chart feels crowded, filter it to late tasks or major milestones.

Why are my baseline bars missing?

The most common reason is that no baseline has been saved. Open the Project tab, select Set Baseline, choose the baseline option, and apply it to the whole project or selected tasks. Also check that the chart is using the Tracking Gantt view and that baseline bar styles have not been hidden.

How do I show a task as late when it is still in progress?

Set the status date, enter the task’s actual progress, and update its remaining duration or forecast finish. Then compare the current finish with the baseline finish. A task can be late even when it has no actual finish because Project uses the current forecast to calculate variance.

Does a delayed task always delay the entire project?

No. A late task may have total slack, allowing the project finish to remain unchanged. Review dependencies, critical path status, and milestone dates before concluding that the project is late. A task with positive finish variance deserves attention, but its effect depends on how the schedule is connected.

Can I highlight delayed tasks with color?

Yes. Use a filter for tasks with positive Start Variance or Finish Variance, then apply a bar style or text highlight through the Format tab. Many teams use one color for late work and another for critical tasks. Keep the color scheme consistent so people understand the chart quickly.

Conclusion

Showing delay in an MS Project Gantt chart requires five actions: save a baseline, record actual progress, set the status date, open Tracking Gantt, and display variance fields.

But here’s the truth: a delay becomes useful only when you connect it to dependencies, slack, milestones, and a recovery action. The chart should help you decide what to do next.

Start with one reporting cycle. Update the schedule, filter late tasks, review the critical path, and discuss the largest milestone risk. If your team needs broader workflow and reporting support, ONES Project offers a structured Jira alternative for tracking work across different deployment environments.