Welcome to Project Management! In this video, I’ll talk about how to develop
a project network. A Project Network is a diagram that graphically
describes the logical sequences, interdependencies, and start and finish times of the project
activities. The network is developed from the information
collected for the work breakdown structure. It provides the basis for scheduling labor
and equipment. It can be used to enhance communication among
project participants, provides an estimate of the project’s duration, and provides
a basis for budgeting cash flow. A project network is a tool that highlights
critical activities that should not be delayed. There are two different ways to representing
a project network: Activity-on-Node network and Activity-on-Arrow network, or AON and
AOA. An AON network uses a node to depict an activity,
and an AOA network uses an arrow to depict an activity. The activity-on-node method has come to dominate
most projects, and we will only introduce this method. In an activity-on-node project network, an
activity can include one or more work packages. The node depicts an activity, and the arrow
shows dependency and project flow. It’s good practice to have the same people
who developed the work breakdown structure to develop the project network to guarantee
the consistency and continuity. Let’s see some terms used in developing project
networks. An activity is an element of the project that
requires time, either work or wait, but may or may not require resources. Activities that consume resources are easy
to understand. Examples of activities that do not require
resources include waiting for contracts to be signed, materials to arrive, drug approval
by the government, budget clearance, etc. The diagram on the right is a part of a project
network. It has four activities, A, B, C, and D.
There are three basic relationships among activities: predecessors, successors, or concurrent. A is C’s predecessor. B is also C’s predecessor. C is A and B’s successor. A and B are concurrent or parallel activities. C and D are also concurrent activities. A merge activity is an activity that has two
or more immediate predecessors. That means, more than one dependency arrow
flowing into it. In this example, C is a merge activity. A burst activity is an activity that has more
than one immediate successor. That means, more than one dependency arrow
flowing from it. In this example, B is a burst activity. A path is a sequence of connected and dependent
activities. For example, A-B-C is a path, B-C-E is a path,
A-D-E is a path. A critical path is the longest path through
the activity network from the beginning to the end that allows for the completion of
all project-related activities. The Critical Path marks the shortest expected
time in which the entire project can be completed. Delays on non-critical paths may not delay
the entire project, but delays on the critical path will definitely delay completion of the
entire project. In this diagram, the numbers above or below
the activities are their durations. Activity A take 2 days to complete, B takes
3 days, and so on. We have two paths from the beginning node
A to the end node E. A-B-C-E and A-D-E. The total length of A-B-C-E is 2 plus 3 plus
1 plus 4. It’s 10 days. The total length of A-D-E is 2 plus 5 plus
4. It’s 11 days. Therefore, the critical path is A-D-E because
it’s longer. There are some basic rules governing the development
of project networks. First of all, project networks typically flow
from left to right. By convention, most project management software
follows this rule when a project network is displayed on a computer screen. Second, the activities will be performed in
sequence. An activity cannot begin until all predecessors
are complete. In the diagram at the top, B can start only
after A is finished. In the diagram at the bottom, Y and Z cannot
start before X is finished. Third, each activity must have a unique identification
code. It could be a number or a letter. An activity’s identification code must be
greater than that of any predecessor activities. A is followed by B, and B is followed by C.
X is followed by Y and Z. Network numbering is frequently not done until
after the network is complete. The fourth rule is that arrows indicate precedence
and flow, and they can cross over each other, like the one at the top. The fifth rule is that conditional statements
are not permitted in a project network. One example of the conditional statements
is “if test is successful then build the prototype; otherwise redesign.” Also, looping is not allowed in a project
network. In the diagram at the bottom, this is an example
of looping. It attempts to return to an earlier activity
from Z to X. If this loop were allowed, this path would
perpetually repeat itself and the project may never end. Many computer programs catch this type of
logic error. The last rule is that if there are multiple
starting nodes in a project network, they should all be tied together to form a common
project start. Similarly, if there are multiple end nodes,
they should all be tied together to form a common end. We use a pseudo or dummy activity as the common
start node and the common end node. In this example, we originally have two starts,
B and C. We introduce a dummy node A as the common
start, so the project has only a single starting node. In this second example, we originally have
three ends, J, K, and L. We introduce a dummy node M as the common
end, so the project has only a single end node. Now, let’s see how we can develop a complete
project network for a smart watch project based on information in this table. This table contains 8 activities, from A to
H. The first step is to identify the project start. Activity A “define requirements” has no predecessor. So, it’s the starting node of the project
network. A is the predecessor of activity B “design
software” and C “design hardware”. So, we draw two arrows from A to B and from
A to C. B is the predecessor of D “code software”. We draw an arrow from B to D.
Activity C is the predecessor of E and F. So, we draw two arrows: C to E and C to F.
D is the predecessor of G. Let’s draw an arrow from D to G.
Lastly, E, F, and G are all predecessors of activity H.
So, we draw three arrows: G to H, E to H, and F to H. And now the network is complete. Note that in this diagram there is no time
information. This is because the durations of the activities
are not provided in the table. Now let’s assume the project manager used
the bottom-up method to estimate the time for each activity. Such time estimates are extracted from the
work breakdown structure, and they are listed at the last column in this table. Activity A takes 20 workdays, B 10 workdays,
etc. Then we can update the project network and
add the duration of each activity. Each activity is represented by a 9-cell block. The bottom right corner shows the meaning
of each cell in a block. This new format will be use throughout this
project management course. ID in the top center cell is the identification
code for each activity, like A and B in this network. The middle center cell shows the description
of an activity, like “define requirements” or “design software”. DUR in the bottom center cell is the duration
of that activity, like 20 workdays, 10 workdays, etc. The other six cells, ES, EF, TS, FS, LS, and
LF contain important time and slack information for each activity. We will fill out these blanks for each activity
block. ES in the activity block means “early start”. It’s the earliest time the activity can start. EF means “early finish”. It’s the earliest time the activity can finish. We will use a method called forward pass to
calculate these earliest times. Forward pass begins with the project start
time, which is usually time zero for the first node. Then we add activity times along each path
in the network. The early finish time EF of an activity is
equal to the early start time ES plus its duration. After that, we carry the early finish time
EF to the successor activity where it becomes its early start ES. However, if the successor is a merge activity,
the largest early finish time EF of all its immediate predecessor activities should be
carried to the merge activity as the early start ES. This process is repeated along each path of
the network until all the activities have been covered. This method may seem complex. Let’s see an example to understand how it
really works. I’ll just put this equation at the bottom
left corner for reference. Activity A starts at time 0. So its early start equals 0. Its duration is 20 workdays. So, Early finish is 0 plus the duration 20
and it equals 20. A has two immediate successors, B and C. Neither
of them is a merge activity. So, we carry the early finish 20 to activities
B and C as the early start time. B has a duration of 10 workdays. So its early finish is 20 plus 10, and it
equals 30. For activity C, 20 plus 50 equals 70. For D, the early start time will be 30. Early finish is 30 plus 40 equals 70. Carry this over to G. 70 plus 70 is 140. Because the successor H is a merge activity,
we have to wait and calculate the early finish time for E and F first. We carry 70 to E and F. 70 plus 100 is 170. 70 plus 30 is 100. Activity H has three immediate predecessors,
G, E, and F. Out of these three predecessors, activity
E has the largest early finish time. So, we carry 170 over to H. 170 plus 30 is
200. Because H is the end node of the project network,
we conclude that the earliest finish time of the whole project is 200 workdays. LS in the activity block means “late start”. It’s the latest time the activity must start. LF means “late finish”. It’s the latest time the activity must finish. We will use a method called backward pass
to calculate these latest times. Backward pass begins by setting the late finish
time LF of the last activity to its own early finish time EF. The late start time LS is equal to late finish
time LF minus the duration of that activity. Then we carry the late start LS to the next
predecessor where it becomes its late finish LF. However, if the predecessor is a burst activity,
we must choose the smallest late start LS value of all its immediate successor activities. Again, let’s explain the backward pass process
using this example. We already know from forward pass that the
early finish time EF of activity H is 200. We start by setting late finish LS of activity
H to 200. So late start equals late finish LF minus
the duration, that is, 200 minus 30. The result is 170. None of its predecessors is a burst activity. So, we carry the late start 170 to activities
G, H, and F as the late finish. For G, the late start is equal to 170 minus
70, which is equal to 100. We carry late start of G to D and repeat the
process. 100 minus 40 equals 60. Similarly 60 minus 10 equals 50. Because A is a burst activity, we should wait
here and do the calculation for other branches. For E, 170 minus 100 equals 70. For F, 170 minus 30 equals 140. C is a burst activity. Its late finish is equal to the smaller of
these two values, which is 70. For C, 70 minus 50 equals 20. Activity A is a burst activity. The late finish should be the smaller of these
two values, which is 20. The late start of activity A is 20 minus 20. We get 0. After we get the earliest and latest times
for each activity, we can use them to calculate the total slack. Total slack is also called total float. It tells us the amount of time an activity
can be delayed without delaying the entire project. It’s how long an activity can exceed its early
finish time without affecting the project end time. Mathematically, the total slack is the difference
between the late start and early start. It’s also the difference between the late
finish and the early finish. Let’s just apply the equation shown at the
bottom left corner to all the activities. For A, late finish minus early finish is 20
minus 20, the result is 0. Or late start minus early start, 0 minus 0;
it’s still 0. So the total slack is 0. That means, any delay in activity A will cause
delay of the entire project. For B, total slack is 60 minus 30, or 50 minus
20; the result is 30. It means the early start, which is day 20,
can be delayed by 30 days to day 50, without delaying the whole project. Any more delay beyond 30 days for activity
B will delay the project. For D and G, they are also 30. For C, E, and H, there is 0 total slack. For F, the total slack is 70. Another type of slack is called free slack
or free float. It’s the amount of time an activity can be
delayed without delaying any immediate successors. It measures how long an activity can exceed
its early finish time without affecting early start times of any successors. Mathematically, the free slack of an activity
is the difference between the early start of its successor and its own early finish. Only predecessors of a merge activity can
have free slack. Other activities will not have any free slack. The smart watch development project network
has only one merge activity, which is H. So, only G, E, and F may have free slack. Therefore, we write free slack equals 0 for
all other activities. We apply the equation shown at the bottom
left corner to activity G. The early start of its successor H is 170. The early finish of itself is 140. So, the free slack of G is 170 minus 140 equals
30. Then apply this equation to E.
The early start of its successor H is still 170. The early finish of itself is 170. So, the free slack of E is 170 minus 170 equals
0. Finally, let’s apply this equation to activity
F. The early start of its successor H is 170. The early finish of itself is 100. So, the free slack of F is 170 minus 100 equals
70. Therefore, activities G and F can be delayed
by 30 and 70 days respectively without delaying their successor activity H.
Other activities cannot be delayed without affecting their successors. After we are done with the computation and
get the complete project network, we can start to identify the critical path. The critical path is the longest path through
the activity network. It measures the shortest possible time in
which the whole project can be completed. It’s also the path that has the least slack. In this example, we have a total of three
paths from A to H. They are A-B-D-G-H, A-C-E-H, and A-C-F-H. For the first path, the length is the sum
of their durations, 20 plus 10 plus 40 plus 70 plus 30 equals 170 days. The length of the second path is 200, and
the third path is 130. Therefore, A-C-E-H is the longest and is the
critical path. It is marked with blue dashed arrows. The project will need 200 workdays to finish. Since the critical path determines the project
completion time, the project manager should put best people on these critical activities
and pay extra attention when doing risk assessment. Critical activities typically represent about
10% of all the activities of the project. The project manager should closely monitor
these critical activities when they don’t have time to monitor all activities. These activities are the ones you won’t even
consider when other managers ask you to ‘borrow’ people or equipment. Network sensitivity measures the likelihood
the original critical path(s) will change once the project is initiated. A network is insensitive if it has only one
critical path and the noncritical activities enjoy significant slack. A network is sensitive if it already has multiple
critical paths and noncritical activities have little slack. So, in a sense, sensitive projects are fragile
and more prone to delays. Let’s check how sensitive this project network
is. There is only one critical path in the network. It’s A-C-E-H. In the non-critical path A-B-D-G-H, there
are 30 days of total slack. In the non-critical path A-C-F-H, there are
70 days of total slack. Therefore, this network is insensitive. All of the tools and techniques discussed
in this video can be implemented with computer software like Microsoft Project. Microsoft Project will do the calculation
automatically and show you the final results and the network after you typed in the start
date, the time unit, and the duration of each activity, as well as non-workdays and sequencing
of the activities, etc. For example, this screenshot shows the schedule
table on the left with information such as ID of each activity, duration, task name,
early start date, early finish date, late start date, late finish date, free slack,
and total slack. On the right side, it also shows the automatically
generated Gantt Chart for the project. In the Gantt Chart, the blue bars represent
the activity durations. The extended lines from the bars represent
slack. This screenshot shows the automatically generated
project network. The critical activities and critical path
are highlighted in pink. Let’s zoom in the top left corner to see the
details. Each block contains the information such as
activity name, ID, early start and early finish dates, and duration. When we build the smart watch project network,
we assume that all predecessors must be 100% complete before the next activity can begin. This relationship is called the finish-to-start
relationship. In real-world applications, this assumption
is too restrictive for some situations involving activities with long durations. Instead of waiting for the entire activity
to be 100% complete, we may break it into multiple segments and start the next activity
after a segment of the predecessor is complete. This is called the laddering approach. It can finish the entire project sooner. An example of the laddering project is building
a road. Huge earth-moving machines must be used to
create a solid foundation. Then, bulldozers and graders move around dirt
delivered by dump trucks to create a level surface. Finally, gravel is added in layers and machines
roll over the surface to compact and flatten it further. We can split the 1-mile road into three segments. After the foundation is done for the first
third miles, we may start the surface work while preparing the foundation for the next
third miles. After the surface of the first third miles
is done, we may immediately start to add gravel. Therefore, the laddering process will finish
the project much faster. A project network may involve relationships
between activities other than finish to start. We summarize these relationships using a term
called lags. The use of lags has been developed to offer
greater flexibility in network construction. A lag is the minimum amount of time a dependent
activity must be delayed to begin or end. Lags can be used to constrain finish-to-start,
start-to-start, finish-to-finish, start-to-finish, or combination relationships. The finish-to-start lag is used in situations
where the next activity in sequence must be delayed even when the predecessor is already
complete. For example, removing concrete forms cannot
begin until the poured cement has cured for 1 day or 24 hours. Or, it may take 1 day to place the order but
take 3 days to receive the goods. The start-to-start relationship with a lag
of 5 time units is shown here. The time units could be hours, days, weeks,
or months. Activity B cannot begin until 5 time units
after activity A begins. The start-to-start lag can be used in laddering
projects so activities can work concurrently, and the projects can be finished more quickly. This is a finish-to-finish relationship. The finish of activity B depends on the finish
of activity A. For example, in a mobile app development project,
software testing cannot be completed any earlier than 3 days after the prototype is complete. This is a start-to-finish relationship. The finish of activity B depends on the start
of activity A. It shows that system documentation cannot
end until 5 days after testing has started. This is probably because all the relevant
information to complete the system documentation is produced after the first 5 days of testing. Lags can also be used to represent a combination
of relationships. This example shows a start-to-start and finish-to-finish
combination tied to two activities. Debugging cannot begin until 3 weeks after
coding has started. Coding must be finished 5 weeks before debugging
can be finished. This diagram shows a project network with
a lot of lags. We can read this network this way. Two days into the design of the system, which
is activity A, it is possible to order the required hardware, which is activity B.
It takes three days after the order is placed for the hardware to arrive so it can begin
to install software, which is activity C. After two days of installing the software
system, the testing of the system can begin, which is activity D.
System testing, activity D can be completed four days after the software installation
is complete. Preparing system documentation, activity E,
can begin once the design is completed (activity A), but it cannot be completed until three
days after the system is tested (activity D). The forward pass and backward pass can still
be used to calculate the information such as early start, early finish, late start,
late finish, total slack, and free slack. Just remember to account for the lags when
doing these calculations. This task is left for you to practice. Finally, the critical path is A-B-C-D-E. The duration of the project, including lags,
is 34 days. To sum up, in this video, we talked about
how to create a project network using the activity-on-node method. We learned how to calculate early times, late
times, slacks, and how to identify the critical path. We also discussed how to use lags to constrain
project activities. This is Yong Wang, and I’ll see you in the
next video.

09 Project Network
Tagged on:                                                                                                                                                     

Leave a Reply

Your email address will not be published. Required fields are marked *