I'm building a project Gantt, involving multiple teams. In the past I've had a good experience with a Gantt as a means of planning a project but not so much as a means of tracking a project's progress.

I'm trying to figure out what would be the best way to reflect the integration points and dependencies between teams and then track it as easily as possible.

Current approach
Right now, what I have in mind is creating tasks for teams' activities and after each task that indicates a delivery to another team I creating a milestone, with the task as its predecessor. The receiving team's task depends on the milestone.


==== [Team A develops]
   +-> * [Team A development complete]
       +-> ==== [Team B develops]

The downside of this approach is that the Gantt gets cluttered with a lot of milestones. The upside is that I get more control down the road around team delivery tracking and an easier way to filter the deliveries of each of the teams. Also, a side benefit is to avoid messing with weird task updates, splits, etc. I would ask for updates to estimated delivery dates.

I'd be happy to hear your thoughts and ideas around this issue. How would you approach this?

5 Answers 5


I've used (and like) a section at the top of the schedule for milestones. This keeps the key milestones visible and easily reportable.

If you really want to use milestones to show links between teams, I would suggest first that the teams -really- be separate teams and not just different roles. For teams that each manage their own schedule, I have found milestone linking like you are describing moderately helpful. Here is how I have done it

Warning - this requires a -ton- of overhead to maintain, I strongly suggest you really understand why this level of tracking is needed...

Give each team their own project file. Each project file has three major "sections"

  • Published Milestones - List of milestones from the local schedule file that are reported up and to other projects
  • External Milestones -List of milestones from other teams or external sources.
  • Schedule - where the actual tasks are for the team

You then control a master schedule that takes each team's schedule and "creates the links" between their milestones. That is, you need to use the "Published Milestones" to drive the "External Milestones" across all of the teams' project files. This is time consuming and for five teams takes a good few days to set up, plus the communication needed to ensure everyone understands the structure. Each week (or whatever your timeframe is for managing the schedule) you need to pull in the teams' projects into the master, observe the links changing, and resolve the issues.

Again, I can't stress enough that this requires a -huge- commitment to the project schedule. I wouldn't attempt this without some of the teams each having their own PM who understands this and can help you work with it. If you can live without a Gantt chart, you might just keep a list of Excel milestones that can be used to communicate across the teams and trust each team to update the milestone list. This gives you 90% of the benefit with 2% of the effort.

  • thanks. Actually, I have used the method you described in the past with 3 teams. As you said, it requires to invest some time and effort on the maintenance side.. I'm trying to be more flexible but still be able to get accurate reports from the teams and be able to see how their changes affect other teams. The method I described is kind of a hybrid - I can filter my Gantt to see a team's milestones and then export it to an Excel for review and updates.
    – OrenD
    Commented May 10, 2011 at 13:59
  • I'm hoping that works. I've found (unfortunately) that the milestones get in the way of the team's understanding of their deliverables. For example - linking to the end of "create draft" instead of to the end of the deliverable (to signal another team needs to review the draft). Causes too much concern about holding the team accountable to interim releases. Hope your method works! (would be nice to hear follow up on success/issues!)
    – Al Biglan
    Commented May 10, 2011 at 21:00

You do not need to use milestones to show the task relationships. In your schedule, once you have determined the sequence of work, based on BOTH hard and soft logic, link them. Link them using FS, SS, FF, with the appropriate leads and lags as appropriate. Baseline it and go.

This should provide you with the control you need.

  • That was the first thing that came up to my mind. I didn't understand why such approach would not be the best approach for this case. It sounds quite obvious that linking them would be the answer...
    – Tiago Cardoso
    Commented Sep 28, 2014 at 19:14

Actually, I like how you're planning it. I think part of the problem is that you're now focusing on the aesthetics of the gantt chart as opposed to what it's being used for. Who cares if it 'looks' cluttered? The only real question is - does it make sense to you, and can you quickly and easily see and find the information you need?

  • thanks. When saying that the Gantt would get cluttered with milestones I did not mean cluttered in terms of aesthetics but rather in terms of how easy it would be for me to find my way through all the tasks and milestones. Nevertheless, if my Gantt is not aesthetic, it's harder for me to maintain it. It's just my personal deficiency. :-) My main use case for maintaining the list of milestones is to be able and filter in a team's deliveries and deliveries expected from other teams and update the team's commitments.
    – OrenD
    Commented May 10, 2011 at 14:07

I tend to use milestones to mark key meetings or approvals of work. If there is some sort of formal cut-over process, make it a milestone.


How about tracking deliveries between teams and as a separate list? This list would be managed by the program office. Each party would need to mutually agree upon what each delivery will contain and when it will be made. Once they sign up these agreements would be as binding as schedule milestones. This list would be used in addition to a master schedule - it does not replace a schedule.

The number and status of these hand-offs also makes a useful metric. The practice provides teams a way to ask for and get attention for things they need from one another.

  • thanks. This approach could work just fine. The downside would be keeping the deliveries list in sync with the project Gantt. I'm expected to report the project schedule in the form of a Gantt.
    – OrenD
    Commented May 10, 2011 at 14:02
  • Right, the delivery list would be tracked separately from the project schedule. I've seen it done this way because these deliveries do not always synch with schedule milestones. As each delivery has an agreed up due date it can be tracked and reported in addition to schedule tasks. It is one way to avoid messing with weird task updates and splits mentioned in the question.
    – Steve Roe
    Commented May 10, 2011 at 16:54
  • You're absolutely right. I've used your proposed approach before in other projects and it worked great. The project I'm getting into is far more complex in many ways I didn't describe here (e.g. some teams work using Agile and others use kind of a phased waterfall approach, some teams are contractor teams while others are part of the organization, new technologies, numerous other dependent projects, etc.). I think I'll give my approach a try and stop to retrospect at some point.
    – OrenD
    Commented May 10, 2011 at 17:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.