Gantt view: seeing the project timeline on one screen

Tuesday, 9:20 a.m. A project manager at an architecture practice is trying to answer one client question — when will the permit package be ready? — and checks three places to do it: a spreadsheet, last week's messages in the team channel, and a notebook. All three give a different date. The real answer sits in a single chain: mechanical drawings cannot start until the structural set is approved, the package cannot be assembled until mechanical is done, and nothing can be filed until the package is assembled. Everyone knows that chain by heart. Nobody has ever drawn it. So the date gets recalculated every time it is asked for, and slips a little each time.

A Gantt view exists to draw exactly that chain. This article works through it in order: where a Gantt view departs from a calendar, which tasks earn a place on the time axis, how dependencies go right and wrong, which work the critical path runs through, where buffer belongs, how planned duration compares against what actually happened, how workload pile-ups become visible, whether the client should see the team's timeline, the difference between sliding a date and re-planning, which teams a Gantt chart does not help, and the weekly rhythm that keeps the drawing alive instead of decorative.

Where does a Gantt view depart from a calendar?

A calendar shows what fits inside a day; a Gantt view shows how long something takes and what it comes after. The difference sounds small and it changes the question entirely. On a calendar a task is a point — the due date. On a Gantt chart it is a bar with a start, an end, and a link to whatever must finish first. A calendar answers "what is due Thursday." Only a Gantt view answers "for Thursday to hold, what has to start today."

In practice: a late task on a calendar turns red inside its own box and stays there. A late task on a Gantt chart pushes every bar behind it. The cost becomes visible on the same screen, and the conversation stops being "we're two days behind" and becomes "two days here moves delivery by a week, because there's an approval window in between." In Rocketly's task management, four views — Kanban, list, calendar and Gantt — read the same task pool; switching the view does not change the data, only the question you are asking of it. Keeping the Gantt chart in a separate planning tool is a textbook case of why consolidating ten apps into one platform keeps coming up: when the plan lives in one place and the work lives in another, the two drift apart within a month.

View	Question it answers	When you open it
Kanban	What stage is this in, and where is it stuck?	Daily stand-up
List	Which items match this filter?	Bulk edits and handovers
Calendar	What is due which day this week?	Planning your own day
Gantt	What order makes this date achievable?	Setting a plan, and when it breaks

Which tasks earn a place on the time axis?

The most common Gantt mistake is charting every task. Pour a thirty-item checklist onto a time axis and you get an unreadable staircase nobody opens twice. To belong on the chart, work has to carry three things at once: a measurable duration, a single owner, and a real successor. Missing any one, it belongs in a list or on a board.

A useful filter: if delaying this by two days changes no other date, it does not belong on the chart. Every bar is a commitment, and work carrying none crowds the drawing and hides the chain that matters. That is what the subtask and dependency structure is for — the parent stays one bar, the detail lives underneath. This is one of the first things skipped when a growing team sits down to sort out project management basics for a small or mid-sized business: a plan gets useful by staying at the right altitude, not by getting more detailed.

How are dependencies built correctly, and where do they go wrong?

A real dependency is a logical impossibility: the second task physically cannot begin until the first ends. You cannot plaster an unbuilt wall, proofread an untranslated file, or issue a production order before the site measurements are in. Everything else is preference, and drawing preferences as dependencies makes the plan far more rigid than the work is.

Three failure modes recur. Mistaking habit for sequence — "we always do this first" is culture, not a constraint. Drawing a person bottleneck as a work dependency: two independent tasks that simply share one owner, which is a capacity problem hidden as a sequencing one. And hanging everything off a single milestone, so when it moves the whole chart turns red at once and stops carrying information. In field-to-invoice operations the distinction is unusually clear, and it is visible in how work order management runs as a single flow: the sequence comes out of the nature of the job, not out of who is used to doing what first.

Which work does the critical path run through?

A project's end date is set by its longest dependency chain, not by all its tasks. That chain is the critical path, and a one-day slip on it moves the finish by a day. Work off the chain has float: it can miss its own date without moving the project.

That distinction changes the first question you ask when a delay is reported. Instead of "how far behind are we," you ask "is this on the chain." If no, you may not need to intervene at all; if yes, you need to intervene today. The chain also tells you where adding people would help — a second person on off-path work will not pull the finish date forward by a day. On long design cycles the reading matters even more, because in work like project and proposal management at an architecture firm the critical path usually runs through approvals you are waiting on from outside, not through your own team's hours.

Where does buffer belong in a plan?

The instinct is to pad every task a little, and the result is predictable: padded work expands to fill the padding. Buffer buried inside a task is invisible, and invisible buffer gets spent without anyone deciding to. The right place is at the end of a chain and immediately before any milestone that depends on someone outside your team.

Approval steps deserve buffer above all, because you do not control the clock there. Client sign-off, a permitting authority's response, a supplier confirmation — each is a window that enters your plan from outside. Where material selection and client approval loop around each other constantly, this becomes the backbone of the schedule; almost everything worth saying about managing the approval cycle on interior design projects is really about where the buffer sits. Drawing buffer as its own visible bar means that when you spend it, you spend it deliberately.

How do you compare planned duration against what actually happened?

A Gantt chart is an estimating instrument, and you only learn how good the estimates are by measuring. That is where time tracking comes in: hours logged against tasks feed the Task Durations report, which shows how long work actually took to close. If you drew a three-day bar and it closed in four and a half, drawing three days again next time is not a plan, it is a wish.

Run that comparison by type of work, not by person. "Who is slow" puts a team on the defensive; "which category do we systematically under-estimate" fixes the plan. With repeating deliverables, two months of this produces a surprisingly accurate estimating table — the shift from instinct to evidence in managing delivery dates at a translation agency is the standard example.

How do workload pile-ups become visible?

A Gantt chart shows time, not capacity. Six bars side by side in one week say nothing about all six belonging to the same person. The plan is internally consistent and still impossible.

Closing that gap means reading the time axis alongside workload data. The Task Load report shows how much open work each person carries; for managers, the team summary answers the same question person by person — who is behind, where the pile-up started. Checking both before sliding a bar two days right is what keeps a plan honest. When the team is distributed the pile-up is even harder to notice, and the first step in building visibility across a remote or hybrid team is to stop guessing at who is carrying what.

Should the client see the same timeline the team works from?

No, and failing to separate the two manufactures crises that need not exist. The team's chart is task level: dozens of bars, subtasks, internal dependencies. A client needs milestone level — which deliverable lands when, which approval is expected when. A two-day internal shift may not move a milestone at all, but a client watching the internal chart reads every shift as a delay.

The rule: externally show only the dates you committed to; internally show the whole chain producing them. Those dates are already part of the agreement — with contracts tracked from signature through renewal, a gap between the milestone in the plan and the delivery date in the contract surfaces while there is still time to act on it.

What is the difference between sliding a date and re-planning?

Two different operations, and confusing them is how a plan loses credibility. Sliding a date leaves the chain's structure unchanged and starts one task later. Re-planning changes the chain itself: a step drops out, two swap order, a new dependency appears. The first is routine weekly maintenance; the second is a decision that needs discussing rather than quiet application.

Recording the difference is what makes "why did this date move?" answerable three months later. The activity history on every task holds who changed what and when, and when a reminder is pushed out, the reason you write under snooze-with-a-reason lands in the reminder history. Slide quietly, re-plan with a reason on the record, and the project review two months from now stops being a memory contest.

Which teams does a Gantt chart genuinely not help?

The honest answer: any team whose work has no fixed duration and no real sequence. Support tickets do not belong on a Gantt chart — you cannot know when they arrive, and none waits on another. Neither do pipeline opportunities, which move on the buyer's decision, not your schedule. Continuously flowing operational work is the same: the drawing is wrong a day after you make it.

The right surface for those flows is a sequence of events, not a time axis — what happened, when, and what is next. Bringing every touchpoint with a customer into one activity timeline is exactly that: there you read the past, on a Gantt chart you commit to the future. A team with both projects and continuous work is better off keeping the two on separate surfaces.

What weekly rhythm keeps the plan alive?

Gantt charts die the same way every time: drawn once, shown in a kickoff deck, never opened after week three. What keeps one alive is not the tool but a fifteen-minute weekly check built around three questions. Which bar moved? Was it on the critical path? Which milestone does that movement reach?

The easiest way to make that stick is to turn the check itself into a recurring task that comes back the same day every week, so nobody has to remember it. On short engagements with a defined end the discipline pays off even faster — when you are running a proof of concept or a pilot project, the window is narrow enough that the weekly check effectively becomes the entire management system.

If you want to try planning tasks, dependencies and a Gantt view sitting next to your customer data instead of in a separate tool, open a Rocketly account and put one project on the time axis.

FAQ

Isn't a Gantt view too heavy for a small team?

The weight comes from how many tasks you put on the chart, not from headcount. A team of five works comfortably with a twelve-bar plan; what exhausts people is pouring a hundred-item list onto a time axis. Chart only the work that has a duration, an owner and a successor.

Can you use a Gantt view without setting dependencies?

You can, but then you have a schedule rather than a plan. Without dependencies you cannot see where a delay propagates. Even drawing just the five or ten links that form the critical path recovers most of the value.

If the plan changes, is the earlier version lost?

No. Each task keeps a record of who changed what and when in its activity history, and a task or project deleted by accident can be restored from the trash. The plan carries both its current state and how it got there.

Can work I plan on the Gantt chart also show up on my calendar?

Yes. The same task pool opens in the calendar view, and you can give a task a time block on the calendar so that when the work will actually be done is planned separately from when it is due. That block mirrors one-way to a connected Google Calendar, and the event updates whenever the block moves.