5.2 Identify the project’s critical path - Video Tutorials & Practice Problems

<v ->So we have this information.</v> And this information, let me just recap briefly. The information that we need here is we know the tasks, we know their predecessor relationships, and we have a reasonable idea of their durations. So using those three values, durations, activities, of course, and their predecessors, we can now create the critical path for the project. Let me explain that term. The definition of a critical path is a little bit counterintuitive, so we have to think this through. The critical path is based on the idea that that network we created last time, that had all those different pathways, it had all those sequence of linked values starting at the beginning and working its way through, all these different paths, one of them is going to define how long the project should take. Another way to say that is this. And this is where the counterintuitive definition comes in, so we want to think about it. The critical path is defined as the shortest amount of time we can use to complete the project. The shortest amount of time necessary to complete a project is determined by looking at the longest path through that network. So the shortest amount of time to complete a project is determined by the longest path. This will become clear when we actually do an example, but what I want us to be thinking of in those terms is when you hear the term "critical path," when someone talks about a project's critical path, what they're saying is a couple things. Number one, how long is this project gonna take? Number two, which activities on your project, on your activity network, which activities are the critical activities? The ones that are on the critical path. Because those are the ones that determine how long the project will be. To put it in another way, if there's any slippage in critical activities, the overall project is going to slip. So how do we determine the critical path? We're gonna do it in a couple ways. There's a couple iterative steps that is involved here. Now, bear in mind, I'm doing this just like I did in lesson four. I'm going through this on a step-by-step process to show us the logic behind it. Computer software is marvelous. And whether you're using one of the big packages, some smaller package, there are many, many scheduling software packages out there that all you do is enter this information, click a button, and it gives you your critical path, it gives you your network, it does all this for you. That's fine. And certainly, I encourage you to be doing that as you move forward in your knowledge of project management. However, it helps if we at least understand the rudiments of where the computer is coming from when it's making all these determinations so that you understand how the logic transpires. Now, in order to create the critical path, we go through a couple processes. The first thing is what we call the forward pass. Now, I'm gonna show this to you in a little while. The forward pass is an additive, we call this an additive move through the network from the starting point, from that first node. Remember, we're going from left to right. From that first node, working our way all the way across to the finishing node, from start to finish. So we're going to do an additive thing. I'll explain what that actually means, but that's the forward pass through the system. Next, where I'm gonna show you, we're gonna be doing a backward pass. We're gonna go from the other direction. We're gonna start at the end, if you will. And we're gonna use this subtractive move to work away backwards through the network from the finish, from the end node, to the starting point. We need both of those activities to take place in order to determine the project critical path. So forward, additive, backward, subtractive. And then as you see there, the critical path will be the longest path from end to end because the longest path is the one that determines the shortest project length. The shortest, the quickest we can complete the project. So the rules that we wanna look at here for creating the critical path involve two activities: the forward pass through the network, and then this backward pass through the network. Now, there's some rules associated with these. There's some terminology you're gonna see on the screen. I'm gonna try and explain some of this to you, but I think you'll pick this up, especially when we do an actual example of it. The first rules relate to the forward pass. Now, early start, that's the ES. Early start is defined as the earliest I can start an activity. So if we think, for example, about the very first activity in our node, all the way over here on the left side, we have time zero. So any activity, if it's starting now, is starting at time zero. The earliest I can finish that activity is a function of when do I start it plus the duration of the activity. So let's say, for example, that I have an activity that's supposed to take four days. It's my very first activity in my network. If I know it's supposed to take four days, then the earliest I can start that is time zero. The duration is four. Therefore the earliest I can finish that is 0 + 4, or 4 days. So my early start is zero, my early finish is four. Now, the next rule says that the next successor activities, the ones that follow behind this predecessor, depend upon that information because that determines the earliest they can start. So for example, if I have that first activity that ends on day four, that day four becomes the early start for any subsequent, follow-on, immediate successor activities to that first one. So that's the idea. The early finish of a predecessor becomes the early start for the successor activities. Makes sense? Then, now is where it gets interesting. Because when we get to merge points, remember, merge points, we talked about those, when we get to a merge point where we have two or more activities coming into a new successor, so we have two or more predecessors, now we have to make a decision rule that says, "When I do this, which one do I pick?" Do I pick the one with an early finish of, let's say, 10, or the one with an early finish of 12? Because they come from different paths, and they're all merging at this point. What we're gonna see in the example I'm going to draw out is that we pick the higher of the two numbers. So we would take 12. That early finish would now become the early start for the successor activity. So it's very straightforward. There's not a lot of rules here, but the ones that there are, we just have to pay attention to them. How do I determine early start and early finish? Well, as I move through the network, the early start for subsequent activities is always based on what the early finish is of the predecessor activities. That's part of the challenge. The second set of computations we're gonna show relate to what's called the backward pass that I mentioned a minute ago. Now, the backward pass we said is subtractive. So now instead of starting at the beginning, what we're gonna be doing is we're gonna be looking at the end of the project. We're gonna be looking at the final node. And we're gonna work our way backward with two new terms. Now we have LS and LF. And LS refers to late start, and LF refers to late finish. A simple way to think about these is this: What is the latest date I can start an activity? What's the latest date I can start an activity and still not disrupt the overall critical path? Like, not disrupt the expected duration of the overall project. That sounds odd, but think about it a second. Not every activity in the path is on the critical path. Therefore, some of them may have what we're gonna call slack time associated with them. So they're not critical. They have to be done, but there's a little bit of wiggle room I have with them. The question of how much wiggle room I have before I have to complete that activity is determined by these ideas. Late start. Well, what's the latest I have to start, let's say, activity J to make sure I don't disrupt the overall schedule? What's the latest date I'm allowed to finish activity J, again, before disrupting the overall schedule? So they're asking really two different questions. Early start is straightforward. What's the earliest I can start the activity? Late start is a little bit more interesting because it's saying, "What's the latest I can get away with starting this activity without disrupting the overall project?" And what we're gonna see in just a minute is that for activities on the critical path, the critical activities, there is no difference between those two numbers. The earliest I can start that activity and the latest I can start that activity have to be at the same amount of time. And we're gonna demonstrate that here in just a minute. But these simple rules will take us a long way now toward understanding how we can manually compute a critical path for a project. So with that being said, let's go ahead and try one. Well, now that we have the rules in place, we're going to actually try developing a very simple example of a project critical path. I'm going to give us an eight-step or an eight-activity project. And notice I have those bits of information that are important to understand. I know what the tasks are titled. Very simply, A through I. I've identified what their predecessors are. And more importantly as well, I've given the expected duration. How did I derive that expected duration? Did I use probabilistic estimates? Did I use deterministic? For now, it really doesn't matter. It's beside the point. The point is, we have derived these estimates for durations. And so these are ones we feel comfortable with, and we're now going to apply them to those different activities. And we're going to construct our critical path by doing a forward pass and a backward pass. Now, the first thing we do in doing this is we create the actual activity network. Remember, we only need two of the columns to do that. If we have the task titles and we have the predecessors, we can use that information to actually create the network activity chart. So the schematic will be on the screen here in just a minute. And then we're gonna take that information, add the durations, and calculate the critical path. Well, we identified a set of rules just a couple minutes ago for developing the critical path. And what I just created and showed you before was another sample work breakdown structure that shows the activity precedent with one additional component because now that we've talked about duration estimates, I've also added in the amount of time each of these activities is expected to take. So we have the days for the activity, the label of the activity, and the predecessors for that activity. So what what I'm gonna do is I'm gonna take this information, and I'm going to apply it to an actual schematic here to show you how we would create and calculate the critical path for this particular project. For those of you interested, again, in taking a look at how I derived these, you can go back to lesson 4.4 and see how I actually took the information that we just had on that slide, and then converted it to this sort of network diagram. Or you can work it along with me and understand the different steps, the predecessor, successor relationships as we go. So what I wanna do now is apply those particular rules. In order to do that, I said a minute ago that we do two things. We create a forward pass through the network. We create a backward pass. And those two combined are gonna allow us to understand overall the critical path of the project. Another thing we're gonna do is I'm gonna illustrate now here something that was in lesson four where I showed you a fully labeled node. If you recall, each of these activities, in other words, that is a node. Now, those nodes consisted of an early start, early finish, late start, late finish, duration, some side of identifier, and what we're gonna find is if there's any slack associated with it as well. So you have the basics here. Now we're gonna build this and show you not only how to calculate a critical path, but how do you actually create those fully labeled nodes at the end of this. Okay? So let's remember our logic. First thing, then, we're gonna do is create the forward pass through the network. This starts at the beginning, and we're going to be moving through the network, okay, from left all the way to the right. And in order to do that, we're going to label the early finish and early start times for each one of these nodes. Now, recall that early start plus duration equals early finish. That's a fancy way of saying that when we start something plus how long that thing takes is when it's gonna finish. Makes sense. So in order to do that, we look here. We recognize that anytime we start an activity or a network, it's always gonna be in time zero. Time zero. So that means now. So we're gonna start always with a zero at the beginning of that node. Then we add the duration, which is four. So we have 0 + 4 = 4. That information now carries forward into the next activity. So this B is gonna start on day four. C is gonna start on day four. 4 + 9 is 13. So the earliest I can finish activity B is on day 13. C is 11 days duration, so the earliest I can finish that is 4 + 11, is 15. So we keep moving in this direction. So far we haven't had any real particular hiccups. Everything is moving smoothly. So we see now that 13 is the early finish. That becomes the early start for the next activity, moving forward. So 13 + 5 is 18. Our early finish is 18. For E, we have 13 + 3 is 16. And down here for F, well, we started with 15, so we bring 15 over. Plus 7 is 22. So far so good. Everything is moving in the right direction. Everything is simply a matter of adding the early start plus the duration to create the early finish. Now's where it gets interesting. Notice that we have E and F are both going into activity G. In other words, G is a merge activity for these two previous ones. One thing we know from the rules is in cases of a merge activity, you take the higher of the two early finishes. That becomes the early start for the next one. So we take the 22. Why do we do this? Very simply, think about it logically. If I know that this activity ends on day 16, but this one doesn't end until day 22, the earliest I can complete, or I can start activity G, which depends upon the completion of both of these, has to be the larger of the two numbers. Can I start activity G on 16? No, because this one isn't done yet. So that's why I take the larger of the two numbers. That's a merge activity. Wait, I have one more. I've got D, which ends on day 18, and I've got G, which is going to be 22 + 3, is 25. 18 + 25. Well, that's easy. So 25 + 2 is 27. 27 + 1 is 28. So what I've done with this forward pass is I've told you how long this project is expected to take. So based on the way the network logic is laid out, based on the rules for assigning early starts and early finishes to each each of these activities, the forward pass gives me the total project duration: 28 days. That's the good information. That's the good news. I've got a 28-day project here. That doesn't get me to the critical path though. That doesn't tell me which of these activities are critical, which are not critical. It doesn't tell me which of these activities maybe has a little bit of slack, little bit of spare time, if you will, built into them, and which ones are absolutely critical to the project. So we're not done. We have just created the forward pass, but now what we have to do is we have to go one step further. We have to create a backward pass. Now, a backward pass starts at the very end of the network. And we always start, if we know that this ends on day 28, we start the backward pass the same way. So backward pass now starts on day 28. The difference here is that for a backward pass, the late finish minus the duration gives me the late start. So late finish minus duration means my late start is day 27. That carries over. Day 27 - 2 is day 25. Okay, I can bring that down here. 25 and 25. And minus 3 is 22. Minus 5 is 20. Now I've got my first interesting point here because I've got 22. Well, 22, we knew, goes into this. It goes into this because there's no problem here. We're not trying to decide between two. Both of these can power in this direction. So this is 22 - 3, is 19. This is 22 - 7, is 15. Let's keep the logic going here. 15 now becomes the late finish here. Minus 11 is 4. Now's where I have some fun. Notice I have a late start here of 20 and a late start here of 19. Now, the logic now works in reverse. So when I have this situation and I wanna understand what's the latest this can finish, it's got to be this one. The latest it can finish is because I can't finish any earlier than day 19 because that one finishes on 20. So we've got 19 - 9 is 10. And same situation, 10 or 4. Which one do we take? We take the smaller of the two. So we take 4 - 4 is 0. Now, that by itself doesn't tell us a whole lot of information. Okay, it's getting us there, but it's only getting us there. Because what we don't know yet is the more interesting information, which is, what's the critical path? How do we determine that? So we can determine the slack, the amount of slack for each one of these activities, through one of two things. We can do late finish minus early finish, which is this minus this, or we can do late start minus early start. Late start minus early start. Either one of these will give us how much slack there is in those activities. So let's walk through this to see. 27 - 27 clearly is 0. 25, 0. We're still on zeros. Okay, now it gets interesting. 20 - 13 is 7. 19 - 13 is 6. 15 - 15 is 0. 4 - 4 is 0. 10 - 4 is 6. And 0 - 0 is 0. Remember, critical activities in a network are defined as those that have no slack in them. Now, what that means in practical terms is that anytime an activity has no slack, if there's a delay in that activity, what that means is it's going to delay the overall project. So any activity that has zero slack in it has no wiggle room. There's no breaks here. We have to make sure that we get these done on time because any slippage in any of those is going to lead to overall project slippage. Look at it this way. The way we determine the critical path, remember, path is the linked set of critical activities. So we know we have zero, zero, zero, zero, zero, zero. So we can say that the critical path for this project consists of the activities A, C, F, G, H, and I. That's the critical path. That's the path that determines how long the overall project is gonna take. These other activities, D, E, and B, all have some slack time associated with them. Now, what that means is, in practical terms, that if F is delayed, the overall project could potentially be delayed. If E is delayed, it's not going to have an impact on the overall project. Why? Because there's six extra days that E has. So if E is delayed up to six days, we're still okay. That has now become maybe part of the critical path, we've lost all of the slack in that activity, but that hasn't delayed the overall project. The overall project is delayed by the critical path. Well, we've just seen how I ran through a forward pass and a backward pass to determine the project critical path. That certainly is a very computational approach. Imagine, instead of having those eight activities, if we had 80 or 800, or in some cases, 8,000. Clearly, we couldn't crunch one of these out, nor would we want to. There's no particular reason to do it when we have some very powerful software packages that can do it for us. However, what I want you to be aware of is that just from a logic point of view, you can now see, when we talk about a forward pass that establishes project duration, and we conduct the backward pass, which allows us to determine activity slack and the overall critical path, that that gives us a means to understand where these ideas come from. So we're starting now to think in terms of how do we understand and set up the critical path for a project. I can take that same exact information and I can input it into MS Project software. So you can see here I've taken my task names A through I. I've determined the duration of them. And you see I've also established those predecessor relationships. So A leading into B and C, et cetera. All those arrows following down to the completion of this project. Looks very different here than it did in my network diagram schematic, doesn't it? And yet the results ultimately play out the same. What I can do if I'm playing with MS Project is I can click on a utility called tracking Gantt. Tracking Gantt. And that'll give me a different view where it shows me the same exact view you see there, with one notable exception. What the software does is it identifies for me the critical activities. So all of a sudden, magically, in red, the bars will appear for the activities that have been determined to be critical. And so that's an alternative way that I can quickly identify the critical path for a project. So you see, we have the computational means to do this, but we certainly also have the software means to do it. Do I prefer the software? Of course. But like anything else, before we start using software, we have to understand where the ideas underlying these software calculations come from. And that was the purpose of what we were doing.