4

I'm taking over a project as a project manager where several functional teams deliver and integrate. Those teams are also delivering to other projects.

Each of the teams is expected to have its own project plan (with the schedule, tasks and milestones depicted in a Gantt). I would like to create a project wide Gantt and I'm considering 2 approaches:

  1. Managing the project in a single Gantt, including all tasks of all teams
  2. Having each of the teams manage their own Gantt, while I manage a high level Gantt with milestones signifying the integration points and deliveries of the teams.

I'm leaning towards the 2nd alternative and wanted to hear thoughts and ideas about these approaches, pitfalls I need to watch for, recommendations I'd rather follow and anything else that could be of help.

  • as a side note, you should clearly distinguish Project Plan and Gantt Chart - they are two different things. – yegor256 Mar 31 '11 at 7:03
  • I totally agree. My oversight and poor choice of words. I've edited the question accordingly. – OrenD Mar 31 '11 at 8:56
4

I have a suggestion and I'll post that here. I would like to clear something up before that.

A Gantt chart is not a project plan. It is a list of tasks to be done, usually with the resources. It could be used as the project schedule. A plan is much more than that. Its one of the project management myths a lot of companies without strucutered PM propetuate, that a Gantt is a project. I've run projects that never got near a gantt chart. Right now the only reason I keep around MS Project files is for showing the execs why they can't have a product release in only eight weeks.

Okay, if I might replace "plan" with "schedule", here is my suggestion.

Go for Option 2: For a number of reasons. 1- Mental sanity: You are effectively the program manager. It's not your job to track the individual projects. Your job is to see if things are on track and to work with a project manager (leader, whoever is the "point man") when a problem rises up that threatens that project. 2- Time: You'll spend all your time reporting and none solving problems. 3- Errors: If you have one shared Gantt file with many users, you increase risk someone steps on someones changes. IF your master Gantt is separate from the project Gantt, you can quickly get out of sync.

I'd take it a step further and ask what you need a master gantt for? Gantt charts are not typically good for reporting up. You can spend a lot of time massaging it to make it look good. If you are just tracking major milestones and are manually inputting that data into the master Gantt that could be a waste of time. I currently use a simple Excel file that has all 30 projects we currently use. I have the major milestones as columns and dates in the cells. I color code the cells to quickly show status and have a notes column for one/two sentence status. 90% of the time I just use this. When I really need a strong "presentation" I copy this into a ppt deck I have that is designed to be an exec dashboard.

Ask yourself who needs the data, how will it be used, how often is it needed (when) and why it is needed. Often you can go with a much simpler solution.

0

I'd go for option 2 as well. Make your "programme" plan based upon the Work Packages you have authorised to the several functional groups. Don't bother to break the work packages down in more detail. That is for the persons responsible for each work package. Reconcile their input with your overall plan.

It is perfectly OK to use a Gantt for this. As long as it shows the network of work packages that result in the growth of maturity of your end result, with all its dependencies.

But a Gantt is not sufficient. Make good agreements upon status reporting. Besides actuals and ETC, measurable physical % complete is required to keep on top of things.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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