Subtasks in a Gantt chart: how to group tasks into phases

A plan with 60 loose tasks in one long list is hard to read, hard to update and hard to explain. The fix is structure: subtasks in a Gantt chart, nested under task groups that represent phases of the work. Done well, a grouped plan lets a client read the big picture in ten seconds while the team still sees every detail.

This guide explains what task groups and subtasks are, how to decide what goes where, and how to avoid the most common structuring mistakes.

Task groups, tasks and subtasks: the vocabulary

Different tools use different words, so it helps to fix the terms:

• Task group (or phase): a container that holds related tasks. It describes an area of work, such as "Design" or "Launch", rather than one piece of work to be done.
• Task: a single piece of work with an owner, a start and a duration.
• Subtask: a task nested under another one. A group's children are subtasks of that group, and a task can in turn be broken down into smaller subtasks.

The group is a label for a stretch of the timeline. The real work, the thing someone does and finishes, lives in the tasks inside it. If you are new to reading these bars, see how to read a Gantt chart.

Why grouping makes a plan better

Grouping solves three practical problems.

1. Readability. Collapse every group and you see four or five phases instead of dozens of rows. That is the view you show a sponsor or a client.
2. Ownership. A phase is easier to hand to one person than a scattered set of tasks. "Alex owns Build" is a clear sentence.
3. Navigation. When a plan grows, you find things by phase first, then by task. Without groups you scroll and search.

A worked example: a website relaunch

Imagine a small website relaunch. A flat list might have 18 tasks. Grouped, it looks like this:

Phase 1: Discovery

• Interview stakeholders
• Audit current content
• Agree scope and sitemap

Phase 2: Design

• Wireframes
• Visual design
• Client review and sign-off

Phase 3: Build

• Set up the CMS
• Build page templates
• Migrate content
• Add forms and analytics

Phase 4: Launch

• Test on devices and browsers
• Fix issues
• Go live

Nothing about the work changed. But now "Build" can be reviewed, moved or reassigned as a unit, and the whole plan fits on one screen when collapsed.

How to decide what is a group and what is a task

Use these rules of thumb:

• If it ends with a deliverable one person can finish, it is a task. "Wireframes" is a task. "Design" is a group.
• If you would report progress on it by looking at its parts, it is a group. You would not ask "is Build done?" without checking what is inside.
• If you cannot give it a single owner, split it. Work shared by three people is usually three tasks under one group.
• Name groups with nouns, tasks with verbs or deliverables. "Build" for the group, "Build page templates" for the task. It makes the hierarchy obvious at a glance.

How deep should you nest?

Two levels is enough for most projects: phases, then tasks. Three levels works for large plans, for example a phase, a feature and the tasks needed for it. Beyond that you are usually hiding problems rather than organizing work.

A few warning signs that the plan is nested too deep:

• Groups with a single child. A container with one item adds a row and no meaning.
• Groups that exist only because "that is how the template looked".
• Subtasks shorter than the interval at which you actually update the plan. If you only review weekly, one-day subtasks create noise, not information.

A good size for a leaf task is somewhere between half a day and two weeks. If you are unsure how long things should be, estimating task durations covers how to break work down and add ranges.

Dependencies and groups

Structure and order are two different things. Grouping tells you what belongs together. Dependencies tell you what must happen before what. A common mistake is to assume that putting tasks in the same group makes them sequential, or that a later group automatically waits for an earlier one.

Link the tasks that really constrain each other. Often the useful links are between the last task of one phase and the first task of the next, for example "Client review and sign-off" before "Set up the CMS". The details are in task dependencies in a Gantt chart.

Milestones fit naturally at the end of a group: "Design approved" closes the Design phase, and "Site live" closes Launch. They give each phase a visible finish line. See what a milestone is in a Gantt chart for examples.

Building the structure step by step

If you are starting from a blank page, this order works well:

1. List the phases first. Four to seven is typical. Do not add tasks yet.
2. Add tasks under each phase as you think of them, without worrying about dates.
3. Check that each phase has a clear end. If you cannot say when a phase is done, it is not defined well enough.
4. Set durations and dependencies once the structure is stable.
5. Add milestones at the end of the phases that matter to other people.

The same approach, with more detail on scheduling, is in how to create a project schedule step by step.

In ProGantt Flow, tasks can be nested as subtasks and grouped under a phase, so you can restructure a plan as you learn more about the work instead of rebuilding it.

Restructuring with an AI assistant

Reorganizing a messy list is tedious work, which makes it a good job for an assistant. ProGantt Flow's MCP connector can read a project as a nested tree, create a task group, and move tasks under a parent, so you can ask Claude something like:

In my "Website relaunch" project, group the build tasks under a new phase called "Build" and tell me which tasks are still not under any phase.

You stay in charge of the decision of what the phases are; the assistant does the repetitive moving. Setup instructions are in the connector docs.

Common mistakes

• Using groups as a to-do dump. A group called "Misc" hides work that nobody owns.
• Phases that overlap without anyone noticing. Overlap is fine and often realistic, but it should be deliberate and visible.
• Never revisiting the structure. As the project moves, move tasks to the group where they now belong. A plan that mirrors reality is more useful than one that mirrors the first draft.
• Splitting too early. Do not break a phase into subtasks until you understand it. A single honest task is better than ten guessed ones.

A quick checklist

Before you share the plan, check that:

• Every group has a clear name and a clear end.
• Every leaf task has one owner and a realistic duration.
• No group has only one child.
• The collapsed view tells a coherent story in under a minute.
• Dependencies connect the tasks that truly constrain each other.

Structure is what turns a list of work into a plan people can read, discuss and trust.