Please login or join to subscribe to this thread
My take on your question is that they each serve their own purpose, and can be used accordingly.
The former is helpful when developing a schedule and when you want to understand critical path, slack and other inputs into schedule optimization and control.
The latter is required to ground your schedule in the reality of calendars and resource availability and is generally an easier method of communicating schedule information than the former.
As Andrew has indicated, both serve their function, and both can be utilized and updated at multiple points over the life of a project.
Dear Kiron and Andrew.
Thanks for your comments.
I usually use first the schedule network diagram for the purpose of understanding critical path, slack and other inputs into schedule optimization.
And I always use it.
There are, however, people who, using technology, just use the gantt chart
I look at both as visualization tools, for the most part. The GANTT chart is helpful for visualizing the full schedule and related tasks. The network diagram is helpful for understanding where you really have slack and what the critical path for the schedule is, as opposed to the "critical" tasks that others are more interested in. This is an important distinction.
I find that while most people outside of project managers are interested in some of this information, they usually want it presented differently. In my circumstances, these have become what I call 'back end project management tools'. They serve a purpose, but not everyone finds them valuable. Since most others don't have the tools I would use to create them, and many can't seem to be bothered to open email attachments, I usually end up summarizing and/or presenting the information in another format others are more willing to consume. I guess you could consider them the "supporting data" that is needed to back up the summary data.
===========warning - personal rant coming===========
I'll be honest; I have a little bit of an issue with this. I don't expect everyone to understand and appreciate project management tools, but it is indicative of a larger issue that I've seen at multiple employers. People want data points, but not enough people want to understand the data points before they make decisions, and they end up making decisions off of data points that may have been manipulated or are biased. After the decisions are made and things fail, they go back and look at the data to see what went wrong, but they don't change their behavior; they keep making the same types of mistakes and bad decisions.
===========end of rant, and apologies for it===========
During planning sessions several decades ago, there was no substitute to having the project team jointly hand-draw the network diagram on giant sheets of paper taped together. At the end of the session, the key project participants possessed both understanding and ownership of the project's execution plan. Then the "software jockey" had the job of turning the diagram into a workable schedule, i.e. the table and bar chart. It seems those days are long gone.
Small, computer-generated network diagrams can be very useful to explain concepts in logic-based scheduling. As they grow, however, legibility (i.e. communication value) goes down while the effort needed to massage and maintain them goes up. In my experience, the point of diminishing returns for computer use is now fairly low, say ~15-20 tasks in a complex network. That's about what can fit on a computer screen.
Legibility (and usefulness for finding redundant or missing logic) is improved by plotting out the network diagrams on large-format paper, taping the sheets together, and posting on a wall or conference table. That's not so useful for communication, however, and large-format plotters seem to be getting rare.
Bar charts that display logic relationships are much more useful for most schedule-communication purposes. They are not as compact as network diagrams, but they can be easily formatted (i.e. filtered, grouped, sorted) to communicate specific issues without much fuss. Unlike network diagrams, they are much easier to comprehend when they take up more than one screen/page of space. Ambiguities in logic can typically be resolved using predecessor and successor details displayed in accompanying forms/tables. In my real projects, these displaced network diagrams for communication more than 10 years ago.
There are also occasional needs for "time-scaled logic" diagrams, a kind of hybrid between network diagrams and bar charts. (The main difference from standard bar charts is that the 1-task-per-row rule is discarded.) TSL diagrams depict the dominant activity durations and controlling logic chains much more intuitively than either of the other options, but they are hard to generate.
Aaron, I enjoyed your rant. Thanks!
I have actually left a long term job over this situation where a new senior manager wanted it all done one way, their way.
I find network diagrams extremely useful, but one of the key factors for when I decide to use them is scale. If you want to present the schedule to someone, there is only so much information you can fit on a page legibly. If you have to wrap your timeline around to fit on a page, or use multiple pages, it is much more difficult to visualize what is occurring. If it is one long line of tasks in series, you're just drawing a list.
It can turn into an exercise in graphics arts rather that scheduling, just moving boxes and lines around. There are some good tools to do this, and I've seen an attempt at a network diagram with hundreds if not thousands of schedule events that spanned an entire conference room wall. I found it unusable.
If the network I am using starts to become too awkward to fit on anything larger than the biggest paper in our printer, I switch to either a Gantt chart, or a "birds-on-a-wire" milestone timeline with specific critical portions broken out into an appropriate visualization format.
Please login or join to reply