How to share a Gantt chart with a client or team

Knowing how to share a Gantt chart with a client is less about the button you press and more about the decisions around it: who should be able to change the plan, who should only look at it, and how everyone finds out when a date moves. Get those right and the schedule becomes a shared source of truth. Get them wrong and you end up emailing screenshots that are out of date by Thursday.

This guide walks through a simple approach, using a small example project, and shows how it works in ProGantt Flow.

Why screenshots and attachments fail

The usual way to share a plan is to export it, attach it to an email and hope. It works once. After that, three problems appear:

• The copy goes stale. The moment a task slips, every attached version is wrong, and nobody knows which one is current.
• Feedback arrives in the wrong place. A client replies to the email with "can we move the review to the 14th?" and now the real plan and the conversation have drifted apart.
• Everyone keeps their own version. Team members paste dates into their own spreadsheets, and the differences only surface in a meeting.

The fix is to share the plan itself rather than a picture of it, so there is only ever one version.

Decide who can edit and who can only view

Before you invite anyone, sort the people involved into two groups. This is the most important step, and it takes two minutes.

Editors: the people who run the work

Editors can change the schedule: add tasks, move dates, update progress, link dependencies. Give this role to people who own part of the plan, such as a team lead, a designer who updates their own tasks, or a co-manager who covers for you.

The rule of thumb: if someone would otherwise tell you "this task is done" or "this will take three more days", let them update it directly. It saves you a round of messages and keeps the plan honest.

Viewers: the people who need to see it

Viewers can open the plan and read it, but they cannot change it. This is the right role for clients, sponsors, finance contacts and anyone who needs visibility without the ability to accidentally drag a bar to the wrong week.

ProGantt Flow has three roles on a shared project: owner, editor and viewer. The owner is whoever created the project; you add the others by email and choose the role for each.

An example: a website redesign for a client

Say you are an agency lead running a four-week website redesign. The plan has these tasks:

1. Kickoff and content audit
2. Wireframes
3. Visual design
4. Client review (a milestone)
5. Development
6. Testing and launch

The people involved are you, a designer, a developer, and a client contact named Ana. Here is how you might set access:

Person	Role	Why
You	Owner	You created the project and are accountable for the dates.
Designer	Editor	Updates progress on wireframes and visual design.
Developer	Editor	Updates progress on development and testing.
Ana (client)	Viewer	Needs to see dates and the review milestone, not edit them.

Ana opens the chart and sees exactly what you see: the bars, the dependencies and the milestone for her review. She does not need to ask "where are we?" because the answer is already in front of her. If the visual design slips two days, the dependent tasks move with it, and she can see the new launch date without anyone writing an update.

Decide what the client actually needs to see

A shared chart shows the whole project, so think about what that means before you invite a client. A few habits make the plan easier for an outsider to read:

• Use clear task names. "Wireframes: homepage and pricing" beats "WF v2". A client should understand every bar without a glossary.
• Group related work. Task groups with subtasks let someone read the top level first and open the detail only if they want it. See task dependencies in a Gantt chart for how links between tasks make the logic visible.
• Mark decision points as milestones. A milestone such as "Client review" tells the client exactly when you need something from them.
• Keep internal notes out of titles. If a task is labelled "waiting on Ana, again", rename it before she sees it.

If some parts of a project are not meant for a client at all, the simplest option is to keep a separate client-facing project rather than relying on people to ignore parts of a larger one.

Keep everyone on the same schedule

Sharing is a one-time setup; staying aligned is the ongoing part. A few routines make it work.

One owner of the dates

Even with several editors, one person should be accountable for the overall schedule. Editors update their own tasks, but the owner reviews the whole chart once or twice a week and decides what to do about slips. Without that, small changes pile up without anyone noticing the finish date has moved.

Update progress, not just dates

Ask editors to keep the progress percentage current on their tasks. A bar at 60% that should be at 100% is an early warning. A task that is quietly late and still shows 0% is how surprises happen. Our guide on how to create a project schedule covers the habit of updating progress in more detail.

Make changes where everyone can see them

Because collaborators work on the same plan, an edit is visible to the others rather than living in a private copy. When a date has to move, move it in the chart and tell people in your usual channel that you did. The chart is the record; the message is just the nudge.

Agree how change requests work

Clients will ask for changes. Decide in advance how: for example, they message you, you check what the change does to the dependent tasks, and you move the dates yourself. Viewer access makes this easy to enforce, because the client can see the impact but cannot change the plan on their own.

Let an AI assistant handle routine updates

If you use Claude or another MCP-capable assistant, it can read the shared plan and make routine edits for you, such as moving a task or answering "what is blocked this week?". It works within your permissions: on a project where you are only a viewer, the assistant is read-only too. The connector docs explain the setup and what it can and cannot do, and our post on managing a project plan with Claude has example prompts.

A quick checklist before you invite someone

1. Is the plan accurate today, with current progress on every task?
2. Are task names understandable to someone outside the team?
3. Is each person set to the lowest role that lets them do their job?
4. Have you told the client what the milestones mean and what you need from them?
5. Does everyone know who owns the schedule and how to ask for a change?

If you can answer yes to all five, sharing the plan will save you time rather than create new questions.

Try it on your next project

Take a project you already have, or sketch the first version of a new one, and invite one editor and one viewer. You can build and share a plan in ProGantt Flow by adding tasks, linking them on the timeline and inviting people by email. Within a week you will notice fewer "where are we?" messages, which is the real sign that the schedule is doing its job.