5.3 Understand the steps to reduce the critical path - Video Tutorials & Practice Problems

<v ->I referred early on to some of the problems</v> and the challenges involved into coming up with realistic duration estimates. And you probably could pick up on the tenor of my conversation there, that I'm concerned that if we don't have a culture, if we don't have a system in place that rewards and allows us to be honest in terms of these estimates, we could potentially create a self-defeating cycle where the boss doesn't trust my estimates, so they constantly shave them. I know the boss is going to shave my estimates so I constantly pad them. And so somewhere along the line, the notion of honest, realistic duration estimates flies right out the window, because we're not trying to improve the project's delivery. We're simply trying to protect ourselves from the blow back that could occur if things go bad. Having said that, if we do create a network, if we create that critical path diagram for a project, and we look at it and we do understand some things, for example, maybe it is too long, maybe the launch window that we have to hit is outside of that value. So if we continue going along the path here, we're gonna blow right past the launch window and we won't get the project out the door when we need to. So the question becomes, under those circumstances, what are some steps for reducing the critical path, some honest means for doing it? Instead of simply shaving 20% and saying, okay let's be done that way, because of course that's artificial. So what are some more perhaps realistic ways that we can look at our critical path and say, are there ways to refine it? Are there ways to shrink down the overall delivery? One way is to ask a hard question. Are there activities that we have currently put in series? Remember, serial activities occur one after another. Are there some activities that we currently have in series that we could potentially move out and put in parallel? So for example, right now, let's say we have a project with 15 activities all identified as being on the critical path overall. Maybe there's 25 activities in the project but 15 of them comprise the critical path. A fair question to ask is are they all legitimately critical activities? Can some of these activities be moved to parallel paths? Because the more we take off the critical path you can see we start shrinking it down because not as much as on the critical path, it becomes shorter. That leads to this idea, all these serial paths, we may have a lot of them in there, how many are are potential candidates for being converted to parallel? Some absolutely may be, some absolutely may not be. Going back to my house building example, clearly we can't bring the finish carpenters in until we complete all the framing work. We can't do the framing work until the decking and foundation are done. So certain aspects have to be done in a certain order in order for the project to take place successfully. On the other hand, many times there's activities that can be done in parallel to each other to try and speed things up. For example, suppose that I'm doing dry walling and painting in that same house, perhaps rather than wait for the entire dry walling to be done, I set it up such that we dry wall half of the house and finish all the sanding, and get that done and then bring the painters in there. And the painters are actually starting on that half of the house while the dry walling is still going on on the other part of the house. And you see what I've done there is simply said instead of waiting for all the dry walling to be done, can we do some of it, get the painters in while we finish that aspect of it? Now, that's kind of a little bit creatively moving some of these activities out of strict serial paths into somewhat parallel paths. That's the kind of thing you should be thinking of. Are there creative ways that I can move things parallel? Can some of the sequential tasks be overlapped? Is it strictly necessary for example, that I wait until all the coding is done for that software project before I can start testing various sequences? Many organizations say no. They say once the first sequence or once the first utility is coded, we send that immediately to the testers for them to start debugging and working on it while the coders are now working on the next sequence and the next and the next. And so we constantly have people busy rather than waiting till all the coding is done, then do all the debugging, then do all the testing. So you see overlapping sequential tasks is a way that we can start streamlining this as well. Well, one obvious example that I also have to put out here, is shorten the duration on critical path tasks. Now, it may be the case, sometimes, that when we first developed that project network, if we look at it and take a hard look at it with fresh eyes, maybe some of those activity durations that we came up with are just a little bit too long. They just really probably aren't necessary to be as long as we've made them out to be. And so when we start questioning the logic underlying that, sometimes it's for honest reasons, somebody misunderstood my directive, and so they gave me an estimate based on a misunderstanding of what I was asking for. Sometimes they're falling back on the old, well, I have to protect myself model. But we have to understand what is the motivation that's linking them to creating those durations that they're coming up with? And use that as a basis for questioning, for shortening, for understanding that. All the time, being honest and imposing this attitude of trust between them and us. I'm not calling you a liar, I'm trying to understand where you came up with this, and if there's ways you and I mutually, can find to shrink that down without imperiling your ability to get it done. So some of the ways we can shorten some of the the rules that are suggested here is if I have an activity network with say 30, 40, 50 activities on it some of the ones that lend themselves to being shortened sometimes are the early ones. Can I find ways, for example, some of those early activities, do they have to be as long as they are or can they be shortened? Longer tasks, this is often a giveaway. Suppose for example, I have an activity that is 12 days, it has been estimated that way. What's the implication of shaving one day off that? Well, in mathematical terms, I'm really only shaving about 8%, a little over 8% of the overall duration of that estimate. So one day off of a 12 day activity is probably not super critical, I'm only taking 8% off of it. On the other hand, shaving one day off of an activity that's been estimated for four days duration could be very critical. Because in that situation, I'm taking 25% of the available time away from that worker. So longest tasks are ones that usually lend themselves to being shortened a little bit just because they are so much longer. So taking a day here or there from those probably isn't going to disrupt the overall flow all that much. Shorten easiest tasks. If we look at an activity, for example, and we notice that this coding, let's go back to my coding example, this coding sequence has to be replicated seven times. But here's the point, you my programmer, have estimated 40 hours work with each one of these coding sequences because it's gonna take you 40 hours the first time. Fair, is it going to take you 40 hours the sixth or the seventh time? I highly doubt it, because you've already done it. Now you've got a repetitive history going here. You've learned something, you have a learning curve example working in your advantage. And so while 40 hours might have been a legitimate estimate for your first coding sequence, by the time we get to number six or number seven, we could very well get that down to about 24 hours without really putting undue pressure on you. So that's another way that we can make use of the fact that some of these activities, because we've done them or because they're easier or they get easier over time, are actually things that are pretty good candidates from being shortened without affecting the overall project. Another one is the idea of tasks that cost the least to speed up. Sometimes I can speed up activities, what we talk about here is an idea called acceleration or sometimes crashing. Crashing project activities usually means this, it means assigning more than one person to do them, adding resources to get it done quicker. Now, there's a couple interesting rules with this that I'm just gonna touch on here 'cause I don't wanna go into them in a lot of detail in this lesson. But a couple things to bear in mind when we talk about crashing activities. Crashing activities works if we haven't started that activity yet. In other words, if I'm in the middle of an activity, this is not the time to add new bodies to it, because these folks don't know what's going on. So I'm actually going to sacrifice a lot of time bringing them up to speed. So if I look at my project network and I think to myself, you know, I have an activity way out there that's going to, it's a relatively low cost activity, it doesn't cost me a lot to put two more people doing that. That might be a good place to add the additional resources in order to get it done faster. Yes, is it gonna cost me more money? Absolutely. But I'm also gonna save days. So by doing that, even though I have more people working on it, they're working fewer days. So you might find interestingly enough, that this all comes out as a wash. Originally with one person, it was gonna take six days. With three people, it's gonna take two and a half days, savings might be right there. So these are just some examples. Please understand the idea of reducing the critical path in some of these steps here requires a lot of creativity. You have to think about this in terms of, okay, here's my network, what can I do honestly and legitimately to shrink this down? The one thing we don't want to do is we don't want to get into some sort of frustrated battle with top management. I've seen this happen in more than one organization. In fact, the worst case, and I won't name the company, but I was consulting with them, and a project manager was getting increasingly frustrated because he had done a good faith estimate to create his activity network. He took it in, showed it to the boss, and he said, boss asked what's the critical path? And he said, I don't know. He said, 70 days. The boss says, that's too long. So he went back to his desk and he sat there and he looked at this set of rules I've just cited to you, and he started trying to be creative and how can I eliminate and shrink and change and all these other things, and he went back to the boss and he said, I got it down to 64 days. The boss shook his head, said, that's still too long. At this point, the project manager looked at the boss and said, all right, let's save ourselves some time here. How long do you want this project to go? And the boss thought for a minute, he says, I can give you 55 days. So the project manager went back to his desk and he got out a big eraser and he started erasing and changing, modifying his entire network, to make it 55 days. Presented it to the boss and the boss said, yes. That's not the moral of the story. The moral of the story is, the after, postscript is, that project came in at 65 days. That's not a surprise. You can do anything you want artificially. I can give you any number you want in the world, but that doesn't mean we can actually pull it off. So for a boss to sit outside of the loop of understanding how this was created and simply arbitrarily say no, 55 days is it, boom, doesn't work Because at the end of the day, the project manager was doing an honest, good faith estimate of how long that project was likely to take. Just because the boss doesn't like that number, doesn't mean that the project manager's wrong. You have to have the same sort of mindset. You have to recognize that if you do a good faith effort, given the resources you're given, the numbers you come up with are likely to be pretty accurate as long as you've taken padding out of the equation. If you can get more resources, you can save some days. But given the resources you start with, if you do a good faith estimate you're gonna be pretty accurate in terms of the overall project duration.