 A project network is probably one of the most critical pieces of information that a project manager needs in order to correctly plan and conduct a project. The project network takes all the work packages from the work breakdown structure, puts them into a network depending on their dependencies, and then from that we can make all sorts of other calculations. We can determine when the project will end. We can determine which tasks are along the critical path. We can determine which tasks can be delayed if needed within our project plan. We also can figure out how we're going to have to allocate our resources over the project time period. We'll also know what is our cash flow going to have to be over the project time period. So a project network is a critical document that every project needs to create at some point or another, and there's basically two approaches to creating a project network. The activity on arrow, which is kind of self-explanatory, as we'll see in a bit, and the activity on node, which is also self-explanatory. Let's take a quick look at this. Activity on arrow, I say it's self-explanatory because we see that the activities are actually represented by arrows. You can see that the length of the arrows may sometimes be used to indicate the relative time that's needed to complete a given task. Sets are where we actually have our tasks intersect, so they are what in some ways provides information about precedence here. And we have a starting node is also referred to as an i-node, and the ending node is a j-node. So for example, you'll see task A's j-node is task B and D's i-node. In each project, when we use an activity on arrow diagramming technique, we'll have a starting i-node and an ending j-node. This technique was used a lot, especially in software planning. It's not used quite as much anymore. The dominant technique seems to be the activity on node. So let's explore that in more detail. Here once again it's somewhat self-explanatory that activity is represented by a node. These nodes do not vary in size or anything like that to indicate their relative amount of time that they take. They are just ordered in a network such as you see here. So the activities are shown in nodes and boxes. We can then tell the precedence from the way in which these boxes are arranged and the arrows are used. So for example, with task D here, we know that task D can't start until both tasks A and B have completed. And the project has a start and an end as well. Now how do we go from having a list of tasks or work packages that we know that we need to be able to complete in order to complete the project to actually having a project network? Well, there's a number of rules that we can follow. The network is going to flow from left to right. An activity can't begin until all of its preceding activities are completed. We're going to use those arrows to indicate precedence. We're also going to identify each task with a unique identifier that can increment in some way or another in a logical fashion. So if we use the numbers 1 through 20 to indicate the tasks in our project, we're going to number our tasks in a way such as we know that task 10 is going to come after task 1 and prior to task 20. We're not allowed to loop through this network. So there's no looping that's allowed. We can't repeat a task several times throughout a network. Conditional statements such as ifs and ors and things of that nature are not allowed. And we also use start and stop nodes. A couple of other pieces of terminology before we get started actually making a network. Activity. It's something that actually requires some amount of work or time. Parallel activity is in this case A and B. We have two activities that can occur independently and if desired they can occur at the same time. But there's no dependency on A getting done before B can start or vice versa. We can also have a merge activity. In this case activity D is a merge activity where A, B, and C have to be completed prior to D being able to start. We can also have the opposite of that which is a burst activity. In this case A is a burst activity. It is the predecessor for both B, C, and D. We can also have a milestone. Milestones are simply markers in our project for when we complete significant events or significant deliverables and that a milestone does not consume any time within our project network. So what we're going to do is we're going to take these various tasks that we've listed these various work packages and we're going to talk with the experts in the field or within our organization on what the dependencies are and we're going to work those out. In this case we've taken these six tasks and have created a relatively simple network. Now each one of these tasks is going to have a number of time related properties. We talked about duration that's pretty easy to define. It is the amount of time that that task is going to take. By knowing the project network and knowing the duration we can then derive these other statistics as well. Let me show you first a little notation that I like to use in order to be able to keep track of all these statistics in one easy marker for drawing our project network. In this case what I like to do is I like to have the task ID at the top in the middle of this top row and then the early start on the left, the early finish on the right, the slack underneath or in the second row. Then in the bottom row I have the late start, the duration and the late finish. This is not something I invented but this is the way that I learned to diagram networks and so this is a I find it a nice way to keep all these pieces of information in one compact three by three area. So let's look at our project network again using this type of notation. So we have our various tasks and we have the duration filled in for them. From this information we can then derive all the other properties but before we do that let's talk about something that we can tell right off the bat here and that's the critical path. The critical path is the path through our network that is going to be most critical because it's going to define when our project ends and any task along that critical path if it gets delayed is in fact going to delay our project. So you can see we have two paths here through the network. So we have A, B, D and E, A, B, D and F and A, C, E and F. So one of those paths is going to be the critical path. It's the longest path through the project network. It's not necessarily the path of the most number of tasks but the one that takes the longest. Any delay of a task on a critical path is also going to delay the entire project so the project manager needs to watch this carefully. Another way to say it is the tasks that have zero slack. So if we look at our project network here we have two paths as we said before A, B, D and F and A, C, E and F. We add up the durations for those and we find that the critical path is A, B, D and F that those tasks add up to 24 let's say days 24 days is going to be now the entire length of our project. So we've been able to determine already the critical path for a project. We'll stop here and in the next video we'll look at how we derive the other time related task properties.