Project Management

Please login or join to subscribe to this thread

Clarification on Network Diagrams

linkedin twitter facebook  
avatar
Soha Karjawally Software development manager / Program Manager| Phoenix - USA Montréal, Quebec, Canada
Hello PM community,

To avoid awkward and long network diagrams, can we consider using it at the high level of the activity where each activity is a list of tasks?

If this is the case, then how to deal with tasks inside an activity that might depend on other ones in another activity in the diagram?

Asking that because I find it complicated in real day-to-day work to use the network diagrams (maybe unless when automatically done via a software?)

Any thoughts, please?
Thanks.
Sort By:
avatar
Keith Novak Tukwila, Wa, United States
Soha,
It is very common to build network diagrams at higher levels of abstraction, just like with Gantt charts. As you've already discovered, if they are at a low level with lots of activities, it becomes unreadable and unmanageable. A good example of this is a deliverable by some team which has a number of technical reviews prior to completion. As a PM, I would typically track the completion, and have a hammock event to capture all those in one single activity on the diagram.

Ideally, you should not have dependencies within those higher level events because it does add complexity. There are a couple things you can do however.

1) Do you need to show all those dependencies on the higher level diagrams? The PM doesn't necessarily track all the minutia as in the hammock event situation, or the diagram may be used to show the plan to a level of management that wants a one page view, not all the details.

2) If the interface is critical, you may be able to break the hammock event into 2 or more events, each of which collects a series of lower level tasks. This may be necessary if you're trying to show the critical path.

3) You may use tiered network diagrams. Different stakeholders manage projects at different levels. You may show an interface on a high level diagram, with a reference to a lower level diagram that contains the details. Engineering drawings often include multiple detail views enlarged for clarity which are referenced in the high level view. Network diagrams can work the same way.

4) Get creative. One of my selling points as a PM is that when there is no readily available solution, I can invent my own. The diagram is a communication tool unless it's built into some automated system that needs to follow the logic exactly. As long as the people using the chart know how to read it, you can get flexible with your solution so that it's both presentable, and contains the level of detail you need.

I hope that helps somewhat.

Keith
avatar
Rami Kaibni
Community Champion
Senior Projects Manager | Field & Marten Associates New Westminster, British Columbia, Canada
Soha

I agree with Keith. Normally we build network diagrams for high level scheduling which will give us info such as Critical Path, Free Float, Total Float.

For each activity, you will have a WBS that breaksdown the activity into tasks that are managed on site.

Hope this helps.

RK
avatar
Soha Karjawally Software development manager / Program Manager| Phoenix - USA Montréal, Quebec, Canada
Thanks, that's helpful!
avatar
Tarun Nair Adoor, Kerala, India
avatar
Sergio Luis Conte Helping to create solutions for everyone| Worldwide based Organizations Buenos Aires, Argentina
PM focus is summary tasks, not detailed tasks. If you go for it then your problem is solved.

Please login or join to reply

Content ID:
ADVERTISEMENTS

"A jury consists of twelve persons chosen to decide who has the better lawyer."

- Robert Frost

ADVERTISEMENT

Sponsors