When organizing a work project, you must determine the most logical order in which to complete the project activities. A useful tool in documenting the workflow is called a network diagram. The network diagram identifies the order in which the work will be completed using logical relationships between the activities.
Depending on the level of decomposition and the complexity of the project, the network diagram may show work packages to be completed for smaller projects, may show only milestones or key activities for larger projects, or may be broken into several workflows displaying different levels of detail for complex projects.
A network diagram helps you understand how the work should really go together so you can then develop a reliable and realistic schedule for your project. Network diagrams reveal the workflow, not just the work. When properly constructed, a network diagram:
The project manager leads the team in defining the most effective and efficient path for completing all necessary work. The network diagram is an effective tool for:
To construct the network diagram, the team must analyze the project activities and identify the relationships and constraints that exist between them. When properly sequenced, the network diagram does the following:
When constructing a network diagram, it is necessary to understand dependencies, precedents, and leads and lags.
The network diagram shown above displays the activities as boxes, which are referred to as nodes. The relationships between each activity and subsequent activities are indicated by the arrows. For simplicity, letters are used instead of the full activity name. The estimated duration of each activity is also shown on the node. The network is read from left to right.
To draw the network, the team needed to understand the relationships between each of the activities. Some activities are dependent on other activities, meaning they cannot be performed unless some other activity occurs.
There are three types of dependencies that may exist:
The project team first determines the external and mandatory dependencies and then works to define discretionary relationships. The latter are important to note as these may be changed at a later date if necessary. When first constructed, the discretionary dependencies reflect the team's opinion of the most logical or preferred sequence for completing the project work.
In addition to identifying the various dependencies, the team must also analyze the precedent relationship between the activities. In other words, what must the state of the preceding activity be before the successor activity can reach a particular state. In the network diagram image above:
There are several types of precedent relationships that may exist between activities in a network.
It should be noted that each activity in the network will have both a dependency and a precedent relationship, except for any that can start immediately. Notice that putting the roof on the house has both a mandatory dependency and a finish to start precedent relationship with building the frame.
Relationships between activities are not always immediate. In some instances, a successor may begin a bit early, or may require a delay before starting. To enhance the network diagram and our scheduling, we can apply leads and lags. These are most often used in Finish to Start relationships.
A lag is simply a delay in the start of a successor activity. For example, we may have a Finish to Start relationship between painting the living room walls and laying the carpet. However, it may be prudent to add a one day lag between these activities to allow the paint to dry. Though this may extend the project schedule, not doing so may cause additional work if we have to clean wet paint off the carpet.
A lead represents a change in the logical relationship that allows the successor activity to start before the predecessor activity actually ends in a Finish to Start relationship. Leads are usually implemented when a successor activity needs to be accelerated in order to shorten the overall project schedule.
For example, though we would normally wait until the blueprints are complete before starting construction, in order to complete a project on time, we may start construction a week before the final drawings are complete. When doing so, the project team is generally taking on more risk and must take that into consideration. In the example, should a significant change be made to the blueprints, the team may have to tear down or change the work already completed.
Jim Muller has been working as a Project/Program Manager for over 20 years. He has managed projects for IT/IT as well as on the business side. Projects ranged from $100 million IS development program, mergers and acquisitions, the launch of business products, and physical relocations of business units. Jim has also worked on the development of internal PM Methodologies, implemented a Project Management Office, and continually provided coaching and mentoring for project management staff. Jim has provided project management training for companies as well as teaching at the university level.