Friday, September 23, 2011

Beginners Guide to Project Management
Part 08, The Gantt Chart


So now you know precisely what is to be done: it’s all in the Work Breakdown Structure (WBS). Now comes the how. How are you to do the things you’re supposed to deliver? What activities are necessary to get the results you need? How long will they take? Who will be responsible for which activities? Which are the necessary skills and competencies? Is there a particular sequence you need for the activities?
You can put all these into a chart that most people (people in general, not Project Managers) find mandatory in Project Management: I introduce you the Gantt Chart!



About Gantt Charts
First a word of warning: Gantt Charts are not all that necessary! Please keep that in mind for the rest of this article. But... In order to build a good Gantt Chart you’ll have to go through a lot that puts all the hows together in your mind. In my particular case, I use them a lot mostly for communication purposes like presentations and reports. A Gantt Chart is well understood by most people not into Project Management (it’s very graphic and somehow pictures are easy to understand) and I find it a very effective tool. It can be really powerful. The point is, the importance of a Gantt Chart is not the chart itself but what you have to do to get it. If you don't need it forget all about the Gantt Chart - except the steps to build it. And that's the reason why it's on this Beginners Guide.
Oh, and Gantt Charts also have an history that is worth checking if you're into these kind of details.

Defining Activities
The first thing to do to develop your Gantt Chart is to define what activities are needed in order to get the deliverables you need for your project. If you look at your WBS, you’ll find all your deliverables on the bottom of each tree branch. Remember that if it’s there then it’s something you have to deliver; and if you have something to do in your project that doesn’t fit any of those deliverables, then it isn’t your project’s work.
Now suppose you have a deliverable “Hardware”. That is what you have to deliver. Take that deliverable and think about how you’ll do it. Instead of a noun like “Hardware”, you should get verbs like “Agree on tech specs”, “Order hardware”, “Deliver hardware” “Install hardware” and so on. These are your activities.
Don’t worry if you find out that you have to change your WBS because you forgot something. Although I’m presenting these planning steps one at a time you will go back and forth between them frequently. Planning is always an iterative process. Also the order in which you approach activities is not fixed. In fact, and in particular in small, simple projects, I usually do all of these steps at once, going through all the steps for each activity, one at a time. Any way you do it is OK as long as you do it and feel comfortable with it.
One way to do it is to put all of your WBS on some Project Management software that can produce a Gantt Chart (you can check some free software on the Software Directory) and add the activities for each deliverable there. You can also start to add some information on these activities like the skills and competencies or even the resources you need for carrying them out. But don’t focus too much on the people unless you already know for sure who will be in your project team.
In longer projects or projects that you have to take one step at a time (like Business Intelligence projects) it is also a good idea not to worry too much about getting all the activities for all the deliverables listed at once in an exhaustive way. The reason for this is that if you don’t know exactly what’s ahead in the long term so why worry now? This kind of approach is called rolling wave planning: you detail what’s coming up next and keep the rest that's further in time with just enough detail to have a wide picture. In very dynamic projects this is also valid: in 6 month the context (technology, business, economic,...) is significantly different - that's why it's called a dynamic project - and require then different activities.

Sequencing Activities
The next step is to sequence your activities when you have a mandatory order (or maybe a best practice or an organization policy that works as mandatory for your project) that must take place. In this “Hardware” example, it’s pretty obvious that you you cannot install the hardware before before it’s delivered and you can’t have it delivered before you order it. This is the kind of sequencing you should focus on.
And don’t forget that the activities for one deliverable can impact other activities for other deliverables. For instance, and going back to the "Hardware" example, you can have another deliverable “Software”. In this case you probably will have to install the software but you need the hardware first, right? Don’t forget these dependencies, you can't look at the activities for each deliverable separated from the rest of the activities. And make them explicit, no matter how obvious they are to you.

Estimation
And it’s now time to estimate durations and resources (human and equipment): and those durations and resources are always related: more resources usually translate into a shorter durations. At this point in time you may know (or not) who will be in your team. If you do, great. If you don’t, think about skills and competencies so that at the end you can say something like: “I need 1 database administrator, 3 programmers and 1 web designer in my team”.
Depending on your project, this estimation job can even be done by people that only do this - this is probably your case if you're in Civil Engineering. Or you can ask the people who will be responsible for the activity to estimate its duration themselves (the Agile way). Or you have enough knowledge about it yourself to provide an estimation. Or you can say “the average time we take to buy new hardware of this type is 4 weeks” and use it. As long as you feel confident about the estimates you use you’re on the safe side.
What you shouldn’t do is something like “a building takes 6 to 18 months to build so I’ll give 24 month as an estimate and play safe at the same time”. This is wrong because:
  • you’re not estimating activities but the whole project,
  • it's almost with a gut feeling,
  • you’re hiding a buffer, and
  • you’re not comparing the building in your project to another one done recently and in the same conditions, materials and so on
And you shouldn't guess. Or try to have exact values (that's why these are called estimates).

And you're ready
If you add a start date, holidays, vacations (if you have a team ready to go), planned absences like training and weekends you get yourself a schedule to guide you. And all this information put together in such a layout is called a Gantt Chart!
You must have seen it before if you've reached this far in this guide, haven't you?

Conclusion
Use a Gantt Chart if you need to:
  • set your own ideas straight or
  • to communicate.
It’s a great tool for these purposes. And later on it may even help you in some other ways that I intend to write about when we reach the Control stage. Just don’t take a Gantt Chart for your project: your project is your team, your deliverables and your stakeholders. These come first. They always do.

Posted by

2 comments:

PMP Certification Class said...

Liked the information shared. Thank you and Great post!

Luis Seabra Coelho said...

Thank you for taking the time to comment on this post!