ProGantt Flow blog

How to manage a project plan with Claude (MCP guide)

2026-10-04T00:00:00Z

Most project plans go stale for a boring reason: updating them is a chore. A task slips, a person gets reassigned, a milestone moves, and nobody has the time to click through twenty bars to keep the chart honest. If you already work with an AI assistant, you can hand that chore over. This guide shows how to manage a project plan with Claude, what the connection looks like, which prompts work well, and where you should keep your own hands on the wheel.

What it means to manage a plan with Claude

Pasting a task list into a chat and asking for a schedule is useful, but the result lives in the conversation. You still have to copy it into your planning tool, and the next change means copying it again.

MCP (the Model Context Protocol) removes that step. It is an open way for an AI assistant to use tools that live outside the chat. ProGantt Flow runs an MCP server, so Claude can work directly on your Gantt charts: it reads the real project, and every change it makes is a normal edit to that project. Open the plan in the web app and you see the new tasks, the moved dates and the updated progress straight away. Anyone you have shared the plan with sees them too.

In practice Claude can read your projects, create a whole plan in one step (with groups, subtasks, dependencies, tags and people), reschedule tasks, update progress, assign people, and report who is overloaded or what blocks a milestone. The full list of tools is in the connector docs.

Connect Claude in three steps

Setup takes a couple of minutes and you only do it once.

In Claude, open Settings, then Connectors, and choose Add custom connector.
Paste the server URL: https://mcp.progantt.com/mcp.
Click Connect, sign in with the Google account you use for ProGantt, and click Allow.

Then enable the connector in a conversation and start with something harmless, like "List my ProGantt projects". If you prefer Claude Code, Cursor or VS Code, those clients connect with a personal access token instead of OAuth; the connector docs have the exact configuration for each one.

You need a ProGantt account first. You can create one at app.progantt.com.

Example: from a blank page to a plan

Say you are launching a small website relaunch and you have no plan yet. Instead of building bars by hand, describe the project:

Create a ProGantt project called "Website relaunch" and draft the plan: discovery, design, build and launch phases, with realistic durations and dependencies between them. Start on Monday 12 October.

Giving an explicit start date matters. If you leave it out, tasks created through the connector start today, and that may not be what you want.

Claude creates the project and adds the plan in a single step. Phases become task groups, the work inside each phase becomes subtasks, and the order of work is expressed as dependencies. Open the chart and you will see something like this:

Phase	Example tasks	Typical dependency
Discovery	Stakeholder interviews, content audit	Starts the project
Design	Wireframes, visual design, review	Wireframes wait for the audit
Build	Templates, content migration, QA	Templates wait for approved design
Launch	Go-live, post-launch checks	Go-live waits for QA

Treat this as a first draft, not a finished plan. The durations are Claude's estimates, and you know your team and your client better than it does. Read the chart, then tell Claude what is wrong: "Content migration needs three weeks, not one" is a perfectly good instruction. If you want a refresher on why the links between tasks matter so much, see task dependencies in a Gantt chart.

Prompts for keeping the plan up to date

The real payoff comes later, when the plan has to survive contact with reality. These are the kinds of requests that save the most time.

Handle a delay

In "Website relaunch", the design phase is running a week late. Push it and everything that depends on it back by 7 days, and tell me the new launch date.

Claude reads the dependency graph, moves the tasks that are affected and tells you the result. The important part is that it follows the dependencies rather than guessing which tasks "feel" related.

Update several things at once

Mark "Templates" as 60% done, tag it "frontend" and assign it to Maria.

Finding a task by its title and applying progress, a tag and a person in one go is exactly the kind of fiddly work an assistant does well.

Check workload

Who is overloaded over the next two weeks? Suggest how to rebalance the work and apply it if I agree.

Claude looks at the load per person for that window, proposes reassignments and only applies them once you confirm.

Ask questions about the plan

What is still blocking the "Beta release" milestone?

Reading a plan and explaining it is often more valuable than editing it. You get an answer in seconds instead of tracing arrows across the chart.

What to delegate and what to keep

An assistant that can edit your plan is powerful, so be deliberate about the split.

Good things to delegate:

Drafting a first version of a plan from a short description.
Mechanical updates: shifting dates after a delay, setting progress, tagging and assigning people in bulk.
Reviews: finding broken dependencies, spotting overloaded people, listing what blocks a milestone.
Summaries for a status update, based on the actual state of the chart.

Keep these for yourself:

Estimates. Claude can propose durations, but the commitment to a date is yours. Check them against what you know about your team.
Priorities and scope. Deciding what to cut when time runs out is a business decision, not a scheduling one.
Anything destructive. The connector can delete tasks, milestones, people and tags, and deletions cannot be undone. Read what Claude is about to remove before you approve it.
Conversations with people. The plan can tell you that Maria is overloaded; only you can talk to Maria.

Safety: what Claude can and cannot touch

Claude acts as you. It sees the projects you see in ProGantt and nothing else, and it respects the roles on shared projects. If you are a viewer on a plan, Claude can read it but every write is refused. When a request is ambiguous, for example a title that matches several tasks, it asks you which one you mean instead of guessing.

Some things stay out of reach on purpose: there is no tool to delete a whole project, to change who a project is shared with, or to touch billing. Those remain in the web app. You can disconnect the connector in Claude's settings at any time, or revoke a token from ProGantt for clients that use one.

A simple weekly routine

You do not need a complicated workflow. Here is one that works for a small team:

Monday: ask Claude what is due this week and what is blocked.
During the week: tell it what finished or slipped, in plain language, and let it update progress and dates.
Friday: ask for a short status summary and a list of risks for next week, then review the chart yourself.

Because the plan lives in ProGantt, your teammates and clients see the same schedule you do. They do not need to use Claude at all.

Getting started

Connect the server, open a small project you already know well, and try one request: move a task, ask who is overloaded, or ask what blocks your next milestone. Once you have seen it keep a real plan up to date, you will know which of your own chores to hand over. The setup steps, the full tool list and troubleshooting tips are in the connector docs, and you can open your projects at any time in the ProGantt editor.

Task dependencies in a Gantt chart: how they work

2026-10-04T00:00:00Z

A Gantt chart without task dependencies is just a list of bars on a calendar. Task dependencies are what turn it into a schedule: they say which tasks must happen before others, so a delay in one place shows up everywhere it matters. This guide explains what task dependencies are, the four types you will meet, and how to use them on a small real project.

What is a task dependency?

A task dependency is a rule that links two tasks. The task that has to happen first is the predecessor. The task that waits for it is the successor.

If you are building a house, you cannot paint the walls until the plaster is dry. "Plaster walls" is the predecessor, "Paint walls" is the successor. On a Gantt chart this is drawn as an arrow from the end of the first bar to the start of the second.

Dependencies answer three practical questions:

What can I start right now, and what is blocked?
If this task slips by three days, what else moves?
Which tasks decide the final delivery date?

Without them you are guessing at all three. With them, the chart tells you.

The four types of dependencies

Project management textbooks describe four relationships between a predecessor and a successor.

Finish-to-start (FS)

The successor cannot start until the predecessor finishes. This is the one you will use most of the time: write the copy, then design the page; build the feature, then test it.

Start-to-start (SS)

The successor cannot start until the predecessor starts. Both can then run in parallel. Example: once "Build the API" starts, "Write the API documentation" can start too, because the writer can follow along.

Finish-to-finish (FF)

The successor cannot finish until the predecessor finishes. Example: "Final testing" cannot be completed before "Last bug fixes" are completed, but testing can begin earlier.

Start-to-finish (SF)

The successor cannot finish until the predecessor starts. This is rare. A typical example is a night shift that cannot end until the morning shift begins.

In practice, the large majority of real plans can be expressed with simple "this must finish before that starts" links. If you are new to Gantt charts, start there and add the other types only when a real situation demands them. In ProGantt Flow, a dependency means that a task depends on other tasks that must finish first, and the chart shows these links as connected arrows.

An example: launching a landing page

Here is a small project with a realistic set of dependencies.

Task	Duration	Depends on
Write the page copy	3 days	none
Design the layout	4 days	none
Build the page	5 days	Write the page copy, Design the layout
Set up analytics	1 day	none
Test on mobile and desktop	2 days	Build the page
Publish	1 day	Test on mobile and desktop, Set up analytics

Notice a few things.

Some tasks run in parallel. Copy, design and analytics have no predecessors, so they can all start on day one, possibly with different people.

A task can have several predecessors. "Build the page" starts only when both the copy and the design are done. If the copy takes three days and the design takes four, the build starts after the design, because that is the later of the two.

Not every task matters equally. If "Set up analytics" slips by two days, nothing changes: it still finishes long before "Publish" needs it. If "Design the layout" slips by two days, the publish date moves by two days. Dependencies make that difference visible. The chain of tasks that sets the earliest possible end date is the critical path, and the longest chain in this example is Design, then Build, then Test, then Publish: 4 + 5 + 2 + 1 = 12 working days.

How to set dependencies well

List tasks first, link second

Write down all the tasks and their durations before you draw any arrows. It is much easier to ask "what must be done before this?" for each task once you can see the whole list. If you are still deciding how to break the work down, grouping related tasks into phases with subtasks keeps the list readable.

Link only real constraints

A dependency should describe something that is physically or logically required, not a preference. "Design before build" is real. "Alice does this before Bob does that because Alice is busy" is a resource question, not a dependency, and mixing the two makes the plan rigid and hard to read. Handle people's availability with resource assignment instead.

Avoid unnecessary chains

If every task depends on the previous one, your project becomes a single long line and every delay is fatal. Ask whether tasks really need to be sequential. Often you can run two tasks side by side and save days.

Watch for circular dependencies

If task A depends on B, B depends on C and C depends on A, nothing can ever start. This usually comes from linking tasks in a hurry. A dependency graph view, or a quick review of each task's predecessors, will reveal the loop.

Use milestones as checkpoints

A milestone such as "Client approval" or "Go live" is a point in time, not a block of work. Tying key tasks to milestones gives you clear dates to report on, and makes it obvious when a milestone is at risk because something upstream is late.

What happens when a task is late

This is where dependencies pay off. Suppose the design takes six days instead of four. Because "Build the page" depends on it, the build, the testing and the publish date all move two days later. On a chart with dependencies you see that immediately. On a spreadsheet you have to remember to change each date by hand, and it is easy to miss one.

After a delay, the useful questions are:

Which tasks are directly affected?
Is the delayed task on the critical path? If not, the end date may not change at all.
Can I shorten a later task, add a person, or run two tasks in parallel to recover the time?

Letting an AI assistant manage dependencies

Writing a plan with a dozen tasks and a web of dependencies by hand is slow. If you use Claude, Cursor or VS Code, you can connect them to ProGantt Flow through MCP and describe the plan in plain language: tasks, durations and what depends on what. The assistant can create the plan in one step, read the dependency graph to find broken links or cycles, and tell you what moves when a task is delayed.

You still decide what the real constraints are: an assistant does not know that your client needs a week to approve a design unless you tell it. Treat it as a fast way to enter and check the plan, not as a replacement for your judgement. Setup steps and example prompts are in the connector docs.

A quick checklist

Before you share a plan, check that:

Every task except the first ones has at least one predecessor, or a good reason not to.
No task is linked only because of habit.
Parallel work is really parallel.
The final deliverable or milestone is reachable through the chain of dependencies.
You know which tasks are on the critical path.

Try it on your own plan

Pick a project you are working on, list ten tasks, and for each one ask: "What has to be finished before this can start?" Then draw those links in a Gantt chart such as ProGantt Flow and look at the chain that decides your end date. Even a rough version will show you which delays you can absorb and which ones you cannot.