Gantt chart examples that show how real projects are laid out
A search for a gantt chart example usually happens at a specific moment. A project has more moving parts than a list can hold, somebody asked "when will this actually be done?", and the team needs a plan that shows the answer at a glance. Templates are easy to find. What is harder to find is an explanation of why a given chart is laid out the way it is, so that the next one can be built for the project in front of you instead of copied from a stranger's.
This article walks through five examples drawn from the kinds of projects small teams run all the time: a website launch, a marketing campaign, a client onboarding, an office move, and a recurring monthly close. For each one, the focus is on the choices that make the chart useful: what goes on a row, how long a bar should be, where the milestones sit, and what can safely be left out.
What every useful gantt chart has in common
Before the examples, it helps to name the parts, because most bad charts fail on one of them rather than on the software.
Rows are units of work that one person or one small group can own. A row called "Design" is a category, not a task. A row called "Homepage layout approved" is something a person can finish and tick off. When rows are categories, bars stretch across months and nobody can tell whether the work is on track.
Bars are date ranges, not effort estimates. A bar that runs for ten working days means the work happens somewhere inside those ten days. It does not mean someone works on it full time. Mixing the two ideas is the most common reason a chart looks fine and still slips.
Milestones are zero-length markers for moments that matter outside the team. A client sign-off, a launch date, a payment deadline. If everything is a milestone, nothing is.
Dependencies are the arrows, or at least the ordering, that say one piece of work cannot start until another finishes. Not every tool draws them, and not every project needs them drawn. But someone has to know where they are.
A today line. The single most useful line on any gantt chart. Any bar that sits to the left of it and is not finished is late, and nobody has to ask in a meeting.
Keep the chart to a depth a reader can scan. For a small team, 15 to 40 rows is a workable range. Past that, split the plan into phases or separate charts, and keep one summary chart that shows only the phases and the milestones.
Example 1: a website redesign and launch
This is the classic case, and it shows why grouping matters.
| Phase | Example rows | Typical bar length | Milestone at the end |
|---|---|---|---|
| Discovery | Stakeholder interviews, content audit, sitemap draft | 1 to 2 weeks | Sitemap approved |
| Design | Homepage layout, inner page templates, design review | 2 to 3 weeks | Designs signed off |
| Build | Templates coded, CMS set up, content migrated | 3 to 4 weeks | Staging ready |
| Test and launch | Browser testing, redirects checked, DNS switch | 1 to 2 weeks | Site live |
Three things make this chart work.
First, the phases are summary rows, and the tasks under them are the real work. A reader who only cares about the launch date can collapse everything and see four bars and four diamonds.
Second, content migration overlaps with build instead of following it. On paper it looks tidy to put content after templates, but in practice waiting for templates to finish before touching content is how launches slip by a month. The chart makes the overlap visible and forces the conversation early.
Third, the milestone before build is "Designs signed off", not "Design finished". The difference is the client. A design can be finished on Tuesday and approved two weeks later. If the chart only tracks the team's own work, it hides the most common source of delay.
What to leave out: individual page builds. Unless there are only a handful of pages, "inner page templates" as one row is enough. Tracking every page as a row turns the chart into a checklist, and a checklist belongs inside the task, not on the timeline.
Example 2: a product marketing campaign
Campaigns have a fixed end date and a lot of parallel work, so the chart runs backwards from the launch.
The rows look something like this: messaging brief, landing page copy, landing page build, email sequence written, email sequence loaded, ad creative, ad account setup, sales enablement deck, internal briefing, launch day, and a two-week follow-up window.
The useful pattern here is working backwards from a milestone. Put the launch date on the chart first. Then place the last task that has to be done before it, then the one before that. When the bars are placed this way, the start dates fall out naturally and it becomes obvious whether the campaign can actually happen on the date someone promised.
Two details are worth copying.
Separate "written" from "loaded" or "built". Email copy being written and email copy being loaded into the sending tool are different tasks, often owned by different people, and the second one always takes longer than expected because it includes testing. Splitting them makes the handoff visible.
Give the post-launch window its own bar. Many campaign charts end at launch day, which quietly signals that the work is over. A bar for "monitor results and adjust" makes it clear that someone owns the two weeks after launch.
In this example, the dependencies matter more than in the website case. The landing page cannot be built without copy, ads cannot go live without the landing page, and the sales deck needs the final messaging. If the tool can draw arrows, use them here. If it cannot, order the rows so that each task sits directly under the one it waits for.
Example 3: onboarding a new client
Agencies, consultancies, and service teams run the same onboarding again and again, which makes it a good candidate for a reusable chart.
A typical layout covers roughly six weeks:
- Week 1: contract signed (milestone), kickoff call, access requests sent
- Week 1 to 2: access granted, current state audit
- Week 2 to 3: findings written, findings reviewed with the client
- Week 3 to 4: plan agreed (milestone), first deliverables started
- Week 4 to 6: first deliverables delivered, first monthly report
The lesson in this example is about the rows that belong to someone else. "Access granted" is a task the client performs. It still goes on the chart, and ideally it is visually marked as external, because it is the row most likely to stall. When access arrives a week late, every bar below it moves, and the chart shows the cause instead of making the team look slow.
Because this chart repeats, it is worth saving as a template with relative dates. The start of every client's chart is "contract signed", and everything else is placed as an offset from that day. Most tools let you duplicate a board or project; the key is to make sure dates shift together rather than being retyped.
For teams that already manage clients on a kanban board, this is also the point where the two views meet. The kanban board answers "what is in progress right now", and the gantt chart answers "is this client on schedule". A setup where both views read from the same cards avoids keeping two lists in sync by hand. The features overview describes how that works when the board type can be switched without copying data.
Example 4: an office move
Not every gantt chart is for knowledge work. Physical projects have hard constraints, and an office move shows how those constraints change the layout.
Rows for a small office move might include: lease signed, floor plan agreed, furniture ordered, furniture lead time, network cabling installed, internet line activated, movers booked, packing, move day, IT setup, old office handover.
This example introduces lead time as its own bar. "Furniture ordered" is a one-day task, but the furniture arrives four to eight weeks later, and nothing can be installed before then. Putting the waiting period on the chart as a bar, even though nobody is working on it, prevents the classic mistake of booking movers for a date when the desks will not exist yet.
It also shows the value of a fixed milestone that cannot move. The old lease ends on a specific day. Everything else is arranged around that date. When a vendor slips, the chart does not move the end date; it shows how much slack is left between the last task and the handover.
The internet line is the row to watch. Line activation times vary by provider and location, and it is often the longest lead time in the whole plan. Putting it near the top of the chart, even though it is technically an IT task, keeps it from being noticed too late.
Example 5: a recurring monthly close
The last example is not a one-off project at all. A finance or operations team closes the books every month, and the same twenty steps repeat on roughly the same days.
The chart spans one month and the rows are the steps: bank reconciliation, invoices sent, expense reports collected, payroll checked, accruals booked, management accounts drafted, review meeting, accounts final.
What this example shows is that a gantt chart can be a calendar of commitments rather than a one-time plan. The bars are short, one to three days each, and the value is in seeing where they cluster. If five steps all land on the third working day and the same person owns three of them, the chart makes the collision obvious before it happens.
For this kind of work, a calendar board or a resource view is sometimes a better fit than a classic gantt chart. A resource view puts people down the side and dates across the top, which answers "who is overloaded on the third" directly. If the team finds itself using the gantt chart mainly to check workload, that is a signal to try the resource layout instead.
Mistakes that make a gantt chart unreadable
Looking across the five examples, the same problems show up whenever a chart stops being used.
Rows that are categories. "Marketing", "Development", "Admin". These give bars that span the whole project and say nothing about progress.
No owner on the row. A bar with no name attached is work that nobody is looking at.
Every task made into a milestone. Milestones are for moments that matter to people outside the team. A chart with thirty diamonds hides the three that count.
The plan built once and never updated. A gantt chart that is correct on day one and untouched afterwards is worse than no chart, because people trust dates that are no longer true. Dragging a bar when a date changes should take seconds; if it takes a meeting, the tool or the process is too heavy.
The chart lives somewhere the team does not work. A spreadsheet chart emailed around on Mondays tends to go stale by Wednesday. Microsoft's own guide to building a gantt chart in Excel notes that Excel has no predefined gantt chart type and that one has to be simulated with a stacked bar chart. That works for a static picture, but a picture is not the same as a plan the team edits every day.
Two plans for the same work. Tasks in one tool and a timeline in another means every date change has to be made twice. One of the two copies will always be wrong.
If the team is choosing where the chart should live, the comparison pages list which tools include a gantt view on which plan, so the decision can be made on facts rather than on which template happened to show up first.
What to change first
Pick the project on your team that most often produces the question "when will this be done?". Rebuild its plan with rows that a person can own, bars that are date ranges, and no more than a handful of milestones, then keep the chart where the team already works so a date change is a drag, not an email. If that place does not have a gantt view yet, Pinateca includes one on the free plan for teams of up to five people.
Q1. How many tasks should a gantt chart for a small team have?
For a small team, 15 to 40 rows is usually readable. Past that, group tasks into phases and keep a separate summary chart that shows only phases and milestones. If a row is too small to be worth a bar, it probably belongs as a checklist item inside a task.
Q2. Should a gantt chart show effort or just dates?
Treat bars as date ranges, not effort. A ten-day bar means the work happens within those ten days, not that someone works on it full time. If workload is the real question, a resource view with people down the side answers it more directly.
Q3. What is the difference between a milestone and a task on a gantt chart?
A task has a duration and an owner who does the work. A milestone has no duration and marks a moment, such as a client approval or a launch date, that matters to people outside the team. Keep milestones few so they stand out.
Q4. Can a gantt chart be reused for projects that repeat?
Yes. Build it once with dates relative to a starting event, such as a contract being signed, and duplicate it for each new project. Client onboarding and monthly close processes are good candidates because the same steps repeat on roughly the same schedule.
Q5. Is a spreadsheet good enough for a gantt chart?
For a one-time picture, a spreadsheet works. For a plan the team updates as dates move, a spreadsheet tends to go stale because it lives apart from the tasks. The chart is most useful when changing a date is as quick as dragging a bar.
