How to show project phases and stage gates on a Gantt chart
Put every task under a phase row, let each phase bar stretch from its first task to its last, and end each phase with a gate: a one-day milestone on the date someone decides whether the next phase starts. Then link the next phase's first tasks to that gate, not to the last task before it. The sponsor sees four phase bars and four gates; the team works from the forty tasks underneath.
The difference matters most when something slips. With phases drawn this way and Auto schedule turned on, a late design review moves the gate, the gate moves the build, and the launch date on the chart changes by itself. With phases typed in as tasks of their own, the chart keeps showing the old dates until somebody notices.
What are Gantt chart phases?
A phase is a group of tasks that share a purpose and end in the same decision. On the chart it is a summary row: its bar has no duration of its own, it simply runs from the start of its earliest task to the end of its latest one. Move a task and the phase bar follows.
A separate task called "Design, 3 weeks" keeps the dates entered at kickoff. A phase summary reflects the tasks underneath, so its forecast updates as the work changes.
| Phase | Task | Gate (milestone) | |
|---|---|---|---|
| Dates come from | The tasks inside it | Its own start and duration | The work it closes |
| Can be assigned work | No | Yes | No, but it has a decision owner |
| Can be linked | Through its tasks | Yes | Yes, and the next phase waits for it |
| Who reads it | Sponsor, client, steering group | The people doing the work | Everyone |
If you are building the phases from a scope breakdown, the guide to converting a scope breakdown covers which levels of the breakdown become phases. Here the focus is the phase layer itself.
How many phases are useful?
Use one phase per major decision, rarely more than six for a project lasting a few months. A phase earns its row when it ends in something a person has to approve: scope, design, a finished build, a go-live. If nobody signs anything at the end of it, it is probably a task group inside a bigger phase.
Two quick tests help:
- The sponsor test. Collapse the chart to phase rows only. If someone outside the team cannot tell from those rows what happens when, there are too few phases or they are badly named.
- The gate test. Write the gate at the end of each phase as a question: "Do we approve the scope?" If you cannot write the question, the phase boundary is in the wrong place.
Name phases after the outcome, not the department. "Design" works because everyone knows what comes out of it. "Marketing" does not, because marketing work usually turns up in three phases.
How do you build phases?
Create the phases first, put the tasks under them, add one gate per phase, then link. The example below is a sample plan for a small company launching a client portal: four phases, twelve tasks, four gates, 48 working days.
- Create one group per phase. Discovery, Design, Build and Launch.
- Add the tasks under each phase. Give each one a duration in working days, and turn weekends off in the timeline so durations count working days.
- End each phase with a gate. Add a one-day milestone as the final row, named as the decision: "Gate 2: design approved".
- Link work to its gate. A finish-to-finish link from the last task puts the gate on that task's final day, so the gate adds no extra day.
- Link the next phase. Its first tasks get a finish-to-start link from the gate, so they cannot start before the decision.
- Check each phase bar. It should start with the phase's first task and end on its gate.
| Phase | Task | Working days | Waits for |
|---|---|---|---|
| Discovery | Interview users | 5 | Nothing, starts day 1 |
| Discovery | Review current process | 5 | Nothing, starts day 1 |
| Discovery | Write requirements | 5 | Both of the above |
| Discovery | Gate 1: scope approved | Milestone, day 10 | Requirements (finish-to-finish) |
| Design | Technical design | 10 | Gate 1 |
| Design | Wireframes | 7 | Gate 1 |
| Design | Visual design | 8 | Wireframes |
| Design | Gate 2: design approved | Milestone, day 25 | Visual design (finish-to-finish) and technical design |
| Build | Set up hosting | 3 | Technical design only |
| Build | Build portal pages | 15 | Gate 2 |
| Build | Connect billing system | 12 | Gate 2 |
| Build | Gate 3: build complete | Milestone, day 40 | Portal pages (finish-to-finish), billing and hosting |
| Launch | User acceptance testing | 7 | Gate 3 |
| Launch | Train support staff | 5 | Gate 3 |
| Launch | Gate 4: go-live approved | Milestone, day 47 | Testing (finish-to-finish) and training |
| Launch | Go live | 1 | Gate 4 |
The same sample plan is shown in Ganttile, starting on Monday 4 January 2027. The grey bars are the phases, the purple markers are the gates, and the arrows that cross a phase boundary all run through a gate.
In Ganttile the phases are lists. A new project starts with three lists, To-do, Doing and Done; rename them and add a fourth. Two settings in the chart menu make the phase layer visible: Show list dates, which is off by default and draws each list as a bar spanning its tasks, and Hide weekends, so a five-day task covers one working week. Ganttile has no separate milestone type: a gate is a one-day task given its own colour, which it draws as a round marker rather than a diamond.
With Auto schedule on, the links do the rest. If Gate 2 slips three working days because the design review is postponed, Build, Launch and the go-live date all move three days, and go-live lands on Monday 15 March instead of Wednesday 10 March.
How do gates control phases?
A stage gate is a milestone with three things attached: a date, an owner, and a decision. On the chart it sits on the last day of the phase it judges, and the next phase is linked to it so that nothing after the gate can be scheduled before it.
The idea comes from new product development, where a project is cut into stages and each stage ends in a go or no-go review. You do not need the full method to borrow the useful part. What a stage gate Gantt chart adds over a plain milestone chart is that the gate controls the dates after it.
- Name it as the decision. "Gate 2: design approved" tells everyone what has to be true. "Design review" only tells them a meeting happens.
- Give it an owner. The person who can say yes. Put the name in the gate's title if your tool has no owner field, as in "Gate 2: design approved (Maria)".
- Book the decision meeting. Put it on the gate's date; an unbooked review can slip quietly.
- Decide what "no" means. A gate that can only say yes is a status update. If the answer can be "redo the wireframes", leave room in the plan or say plainly that there is none.
The guide to milestones and their links goes deeper on where to put milestones and which link types to use for them.
Can phases overlap?
Yes, and most real plans have some overlap. The rule is that the overlap should be deliberate and visible, never an accident of dragging bars.
In the sample plan, "Set up hosting" belongs to Build but starts on day 21, four days before Gate 2. It waits only for the technical design, because the hosting choice does not depend on how the pages look. So the Build phase bar starts before the Design bar ends, and anyone reading the chart can see why: one arrow comes from Technical design, not from the gate.
Starting a later phase early is a form of fast-tracking. It saves time if the gate says yes and wastes work if it says no. Keep the early work to tasks that survive a "no" at the gate. Hosting survives a design change; building the pages would not.
What you should not do is let a whole phase start before its gate because the dates "looked about right". If Build starts before Gate 2 without a link that explains it, the gate has stopped being a gate.
Why do phase charts fail?
Phase charts fail when summary dates drift from tasks, status lists replace phases, or gates lack links, agreed dates or owners. Too many gates also obscure the decisions that matter.
- Phases drawn as tasks. A bar called "Design" with its own typed dates sits above tasks that have moved. The fix is to delete the bar and let the group's summary bar do the job.
- Status lists used as phases. To do, Doing and Done describe where a task is today, not when it happens. Boards imported from a kanban tool often bring these along.
- Gates with no link. A milestone floating on a date, with nothing linked into it and nothing out of it, will not move when the work is late. It will just be wrong.
- Unagreed gate dates. A gate needs an owner and an agreed date. If the design approver has not seen the date, assume it will slip.
- Every handover as a gate. Ten gates in a three-month plan means ten meetings and no clear decisions. Keep gates for the points where the project could stop or change course.
More general chart problems, such as too much detail or bars nobody updates, are covered in common scheduling mistakes.
How do you report progress?
Report by gate dates. For each phase, give the gate's planned date, its current forecast date and the difference. Collapse the chart to phase rows, and the sponsor has the whole project on half a page.
A simple weekly line per phase is enough:
- Discovery: gate passed on day 10, as planned.
- Design: gate forecast day 28 against day 25 planned, because the design review moved.
- Build and Launch: both three days later as a result, go-live forecast 15 March.
Ganttile has no percent-complete field and no saved baseline, so note each gate's agreed date when the plan is signed off and compare against that list at each review. The guide to tracking delays by hand shows a way to keep that record.
For a printed or emailed report, collapse the phases you are not discussing and export what is on screen. Ganttile's PDF and image exports draw the rows the chart is showing, so with Show list dates on, a collapsed phase prints as a single bar. The guide to choosing client-facing detail covers how much detail to show.
Phase and stage gate questions
- Should a stage gate be a task or a milestone?
- A milestone. The gate is the moment of decision, not the work of preparing for it. Put the review preparation in a task before the gate, and the decision itself on a one-day milestone that the next phase is linked to.
- Can a phase depend on another phase?
- It can, but linking the next phase's first tasks to a gate milestone is clearer. In Ganttile, two list bars can be linked to each other when Show list dates is on, yet a gate shows who decides and when, which a phase-to-phase arrow does not.
- What is the difference between a phase and a milestone?
- A phase is a stretch of time that holds tasks; its bar runs from its first task to its last. A milestone is a single point that marks an event, such as an approval. Phases usually end on a milestone.
Where should you start?
Decide the gates first, because they define the phases. Then create one group per phase, put the tasks under it, place each gate on the last day of its phase and link the next phase to the gate. Overlap only where a task can survive a "no".