Understanding Gantt Charts
A Conceptual Guide for Project Managers
How schedules work, why predecessors matter,
and how to use constraints without breaking your plan
1. The Purpose of a Schedule
A Gantt chart is more than a list of tasks with dates attached. When built correctly, it is a living model of your project β one that reflects how work is logically connected, how changes in one area ripple through the rest of the job, and how the project will unfold from start to finish.
When built incorrectly β as a flat list of independent tasks with no connections β it is little more than a spreadsheet with bars. It looks like a schedule, but it does not behave like one.
This guide explains the difference, and why that difference matters every time the GC moves a date, a delivery slips, or your crew sequence has to change.
Two Ways to Build a Schedule
Project managers typically approach scheduling in one of two ways, and the choice has significant consequences for how much work it takes to maintain the schedule over the life of the job.
The Flat Schedule | The Linked Schedule |
Tasks have start and end dates, but no connections to each other. | Tasks are connected with predecessor relationships that define the required sequence. |
Dates are hard-coded. Moving one task does nothing to any other task. | Moving one task cascades automatically through all dependent tasks. |
Fast to build initially. | Takes more thought to set up, but far less work to maintain. |
When something changes, every affected task must be manually re-dated. | When something changes, the schedule recalculates and shows you the impact immediately. |
Feels manageable on a small job. Becomes unworkable on any job with complexity. | Scales to any job size. The more tasks, the more valuable the connections become. |
π¨ The 50-Task Problem A project manager builds a schedule with 50 tasks, each with manually entered dates and no predecessor links. Three weeks later, the GC pushes the floor access date by two weeks. Every single task on that floor now has to be manually re-dated one by one. This is not a scheduling tool problem β it is a scheduling method problem. A properly linked schedule would recalculate all 50 tasks automatically the moment the access date changed. |
2. How Predecessors Work
A predecessor is a task that must be completed before another task can begin. This relationship is the foundation of a functional schedule. Without predecessors, tasks are isolated. With predecessors, they form a chain of logic that mirrors the actual sequence of work in the field.
The Finish-to-Start Relationship
The most common predecessor type is Finish-to-Start: Task A must finish before Task B can start. This is how most construction work is sequenced β one trade clears the way for the next.
Task A finishes β Task B starts
When you link tasks this way, the scheduling tool understands that Task Bβs start date is driven by Task Aβs finish date. If Task A takes longer than planned, Task B automatically moves to accommodate it. If Task A finishes early, Task B can start earlier.
Consider three tasks on the 3rd floor of a commercial HVAC job:
β’ Task 10: Hanger Installation β 5 days
β’ Task 11: HVAC Duct Rough-In β 8 days
β’ Task 12: Register Grilles and Diffusers β 3 days
Physically, duct cannot go up before hangers are in, and grilles cannot be installed before duct is roughed in. The correct predecessor chain is:
Task 10 (Hangers) β Task 11 (Duct) β Task 12 (Grilles)
Now suppose the GC notifies you that 3rd floor access is delayed by one week. You update Task 10βs start date. The scheduling tool automatically pushes Task 11 one week, and then pushes Task 12 one week. You make one change; the entire floorβs sequence updates.
Without those predecessor links, you would need to open Task 10, Task 11, and Task 12 individually and manually adjust each date. On a job with ten floors and a dozen tasks per floor, that is over a hundred manual edits for a single schedule change.
A task can have more than one predecessor. This is necessary when a task cannot begin until several upstream activities are all complete.
Example: A final system test on a floor might require that duct work, controls wiring, and equipment startup are all finished before the test can begin. The test task would have three predecessors β one for each of those activities. The test cannot start until the last of the three is complete.
π‘ Think About the Field, Not the Calendar The best way to set up predecessors is to ask: what physically has to be done before this work can begin? Build the logic from the work sequence, not from the dates. Dates are a result of the logic β they should not drive it. |
Once your schedule is fully linked with predecessors, the scheduling tool can identify the critical path β the longest chain of dependent tasks from the start of the project to its completion. The critical path determines the earliest possible finish date for the job.
Any task on the critical path that slips will push the project end date. Tasks that are not on the critical path have float β a buffer of time before their delay would affect the finish date.
π Why This Matters to a PM Knowing the critical path tells you where to focus when the schedule is under pressure. Not every task that slips is a problem. A task with two weeks of float can slip two weeks without affecting the project finish. A task on the critical path with zero float cannot slip at all without consequences. Without a properly linked schedule, you cannot know which tasks are critical. |
3. Understanding Constraints
Constraints are scheduling rules that restrict when a task can start or finish. They exist to handle real-world conditions that predecessor logic alone cannot address β things like owner-mandated access dates, GC-required milestone deadlines, or equipment delivery windows.
Used correctly, constraints are a precise and powerful tool. Used incorrectly, they override the scheduling logic you have carefully built and can silently break your schedule in ways that are hard to detect.
The Default: As Soon As Possible
Every task starts life with a constraint of As Soon As Possible (ASAP). This means the task will be scheduled as early as its predecessors and other rules allow. ASAP is the right setting for the vast majority of tasks because it lets predecessor logic drive the dates.
Most scheduling problems caused by constraints come from changing tasks away from ASAP when there is no genuine reason to do so.
The Eight Constraint Types
Scheduling tools typically offer several constraint types. Each serves a specific purpose:
Code | Full Name | What It Does and When to Use It |
ASAP | As Soon As Possible | Default for all tasks. Schedule as early as predecessor logic allows. Use this for the majority of your tasks. |
ALAP | As Late As Possible | Schedule as late as possible without delaying successor tasks. Useful for tasks you want to defer until the last responsible moment, such as final material deliveries or late-stage owner-furnished items. |
SNET | Start No Earlier Than | The task cannot start before a specified date, regardless of when predecessors finish. Use when a floor will not be accessible until a certain date, or when a permit is not expected until a specific time. |
SNLT | Start No Later Than | The task must begin by a specified date. Use when a GC or owner has imposed a deadline for work to commence β for example, a noise-restricted activity that must begin before a blackout period. |
FNET | Finish No Earlier Than | The task cannot finish before a specified date. Rare in construction scheduling. Useful when a task must be in progress (or held open) through a certain date, such as a continuous monitoring period. |
FNLT | Finish No Later Than | The task must be complete by a specified date. Use for hard deadlines tied to inspections, owner occupancy, or GC-imposed turnover requirements. |
MSO | Must Start On | The task must start on exactly the specified date. A hard lock. Use sparingly β only for activities with fixed start dates that will not change under any circumstances, such as a mobilization tied to a contract date. |
MFO | Must Finish On | The task must finish on exactly the specified date. A hard lock. Use only for non-negotiable completion deadlines where early finish is not permitted (rare) or for contractual milestones with fixed dates. |
The Constraint Hierarchy: What Wins?
This is the most important concept to understand about constraints: a constraint overrides predecessor logic. When you apply a date-based constraint to a task, you are telling the scheduling engine to ignore what the predecessors are saying and honor the constraint date instead.
This can create a hidden problem. Suppose a task has a predecessor that finishes on June 10, and you have applied a Must Start On constraint of June 1. The scheduling tool will schedule the task to start June 1 β even though its predecessor is not done yet. The schedule will show no conflict. The field will tell a different story.
β οΈ Constraints Can Mask Schedule Conflicts A date-based constraint that is earlier than a predecessorβs finish date creates an impossible schedule β the task is shown starting before it can physically begin. The tool will not always warn you. Always review constrained tasks after making schedule changes to confirm the constraint date is still achievable given the current state of predecessors. |
When Constraints Go Wrong: Four Common Mistakes
Mistake 1: Using a Constraint Instead of a Predecessor
A PM notices that Task B should start around the same time Task A finishes, so they apply a Must Start On date to Task B instead of linking it to Task A as a predecessor. The schedule looks right on day one. Three weeks later, Task A slips β but Task B stays locked to its constraint date. The schedule now shows an impossible sequence.
Correct approach Link Task B to Task A with a predecessor relationship. Let the dates flow from the logic. |
Mistake 2: Locking Every Task with Must Start On
Some PMs, unfamiliar with predecessor logic, manually assign start dates to every task and then apply Must Start On constraints to lock those dates in place. The result is a rigid schedule that cannot adapt. Every schedule change requires manually hunting down and updating every constrained task.
Correct approach Use ASAP (the default) for tasks that should flow from predecessor logic. Reserve Must Start On for tasks with genuinely immovable start dates β which are rare. |
Mistake 3: Using FNLT as a Target Instead of a Deadline
Finish No Later Than is designed for hard external deadlines β a contractual milestone, an owner occupancy date. Some PMs apply it to internal milestones as a way of expressing a goal. The problem is that when the schedule changes and the task can no longer hit that date, the constraint creates a silent conflict rather than a visible schedule overrun. The schedule still shows the task finishing on the constraint date even when it cannot.
Correct approach Use FNLT only for hard external deadlines that are not subject to change. For internal goals and targets, note the target date elsewhere and let the schedule calculate the actual finish date honestly. |
Mistake 4: Forgetting a Constraint Is There
Constraints set during initial scheduling are easy to forget. Months into the job, when the schedule is being updated and tasks are being moved, an old Must Start On or Must Finish On constraint from the kickoff schedule can silently resist changes and produce incorrect dates. The schedule looks updated but the constraint is holding a task in place.
Correct approach Review constraints periodically, especially when re-sequencing work or updating the schedule after a major change. Remove or update any constraints that are no longer relevant. |
4. Building a Schedule That Works
The principles behind a reliable schedule are straightforward. The discipline is in applying them consistently, especially under the time pressure of a job in progress.
Step 1: Define the Work Sequence First
Before you assign a single date, list the tasks for each phase and ask: what order does this work have to happen in? What physically cannot start until something else is finished? Build this logic into predecessor relationships before you think about calendar dates at all.
Dates are an output of the schedule, not an input. The input is the sequence.
Step 2: Set One Anchor, Let the Rest Flow
A well-built schedule typically has one anchor point β a start date for the project or for a major phase. Everything else flows forward from that anchor through predecessor logic. You should be able to change the anchor date and watch the entire schedule recalculate correctly.
If changing a single date requires you to manually update dozens of other tasks, the schedule is not properly linked.
Step 3: Add Constraints Only Where There Is a Real-World Reason
After the predecessor logic is in place, layer in constraints only where an external condition requires them. A floor that will not be accessible until March 15 needs an SNET constraint on its first task. A contractual milestone that must be achieved by June 30 needs an FNLT constraint on the relevant task.
Ask yourself: is this constraint reflecting a real condition in the field or in the contract, or am I just hardcoding a date because it feels safer? If it is the latter, remove the constraint and trust the logic.
Step 4: Maintain the Schedule, Not Just the Baseline
The baseline is a snapshot of your original plan. It should not change unless the project scope formally changes. The current schedule, however, should be updated regularly to reflect the actual state of the work.
A schedule that is updated once at kickoff and never touched again is not a scheduling tool β it is a historical artifact. The value of a linked schedule is realized through regular maintenance: updating task dates as the project progresses, adjusting for changes in sequence or crew, and reviewing the schedule for emerging conflicts before they become field problems.
π The Weekly Schedule Review Set aside time each week to compare the current schedule against actual progress in the field. Update any tasks that have shifted. Look ahead three to four weeks and ask: are there any tasks about to start whose predecessors are not yet complete? Are there any constraints that are becoming unreachable? Catching these issues a week out is a planning problem. Catching them the day of is a crisis. |
5. Reading the Schedule
A Gantt chart communicates a large amount of information visually. Understanding what you are looking at β and what warning signs to watch for β is as important as knowing how to build the schedule.
What a Healthy Schedule Looks Like
β’ Tasks are connected with dependency arrows, not floating independently on the timeline.
β’ The schedule has a logical flow from left to right, with later-phase work appearing further right.
β’ Baseline bars and current bars are close together, with variance clearly visible where the schedule has moved.
β’ Constraints are applied selectively, not on every task.
β’ The critical path is identifiable β there is a clear chain of tasks driving the project end date.
Warning Signs in a Schedule
Term | What It Means |
Tasks with no predecessors | Tasks floating with no connections are not participating in the schedule logic. Any date change elsewhere will not affect them β and they will not warn you when they should. |
Constraints on most tasks | Heavy constraint use is a sign that dates were entered manually rather than derived from logic. The schedule will resist change rather than accommodate it. |
Current bars far right of baseline | Significant schedule slippage. If multiple phases are showing this, the project end date is likely at risk. |
Current bar earlier than baseline | Either the work has genuinely accelerated, or the current schedule has not been properly maintained and tasks were moved forward without basis. |
Dependency arrows crossing backward | A task is scheduled to start before its predecessor finishes. Usually caused by a constraint overriding the predecessor logic. Investigate and resolve. |
No baseline visible | The baseline was never saved, or was saved after significant work had already begun. The original plan cannot be compared against current progress. |
6. Summary: The Rules of a Good Schedule
# | Rule |
1 | Every task should have at least one predecessor, except the very first task in the project. |
2 | Dates are outputs of the schedule logic, not inputs. Set the sequence first; let the dates follow. |
3 | Most tasks should carry the default ASAP constraint. Change a constraint only when a real-world condition requires it. |
4 | Constraints override predecessor logic. Always verify that a constrained task can actually meet its constraint date given its current predecessors. |
5 | The baseline is set once at kickoff and not changed unless scope is formally revised. |
6 | The current schedule is maintained continuously throughout the job. A stale schedule provides no value. |
7 | Review constraints periodically and remove any that no longer reflect actual conditions. |
8 | When something changes, update the schedule and look forward: what downstream tasks are now affected? |