5.1 Employ activity duration estimation techniques - Video Tutorials & Practice Problems

<v ->Welcome back.</v> At this point now, we've talked about several lessons related to conceptualization and planning. Remember, we've focusing on the project life cycle. The last lesson we started getting into the real heart of the planning exercise and the challenge there, we were talking about how do we create activity networks based on that disintegration, if you will, deconstruction of the work breakdown structure. So, we went through an exercise where we talked about the idea of predecessor-successor activities, how then can we use those to create this rational chart showing us how we're going to start the process and finally finish the project at the other end. Now, that got us part way into the process, but by no means, did it complete the challenge because one thing if you notice that was missing from that whole exercise, was any notion of duration attached to any of those activities. At this point, we really haven't talked about how do we estimate the duration of an activity. We've simply tried to identify what those activities are, and create some predecessor relationships among those activities, what has to happen before other things can happen, before other things have to happen. All well and good. However, what we now wanna do is we want to take that and apply another very critical bit of information to that, which is the nature of how long we can reasonably expect those activities to last? What is the duration that should be associated with each one? Now this process, although sounding disarmingly simple, is actually deceptively tricky and there's some tricks, there's some challenges, there's some elements that I wanna walk us through in terms of how we do this to try and make sense of it. Because duration estimation is by no means necessarily a straightforward process, even though it might seem like it on the surface. So, let's talk about some of the basic ideas of duration estimation. The first methods that we're gonna discuss are called deterministic methods. Now, that's a fancy word for a very simple idea. What deterministic methods typically suggest is we have a basis for knowing, we have a reasonably good idea of how long something should take. For example, going back to my residential construction project situation, a builder who has been working in the field for 10 or 20 years, is remarkably able to determine within a very, very finite range exactly how long different activities are likely to take. For example, if I'm building a 2,500 square foot ranch style house and I know how long the trenches are gonna be for the foundation, I know how long it's likely to take to pour the footers, or how long it's likely to take to put the block in, how long it will take to deck that block, that foundation, and on, and on, and on. So certain activities, particularly in construction, we have very good ideas of how long they should take. And hence, we refer to these as deterministic methods. Now, some of the ways that we invest or embed our ideas of what is the right amount of time, is looking at some basic past experience. Going back to my example of the builder, a builder has been doing this so long, and in so many different ways that they really know, they can tell you within a very fine line of variance, how long it's gonna take to do these different things. Why? Because of past experience. They've just done it so many times. Another way, is we tap into our experts. Somebody who's perhaps has done it before, or at least, even if they haven't done precisely this before, they have a very good idea of how long something should take. For example, they may say, "In my experience," or "Based on my best guesses," "If I'm gonna code this sequence, it's going to take 40% of that time additionally to run all the testing on the the code or something to that effect." In other words, ask an expert who has either had past experience or is in a good position to give you more than just a guess but really a best guess or an idea of exactly or pretty close to how long that should take. Either way, the beauty of deterministic estimates are, they take a lot of the margin for error out of the process. We can either go to the experience, we can go to past historical records or the experts and come up with an idea how long these things should take. Now, having said that, we have to be very careful of a couple things because although it is true that deterministic estimates are predicated on the idea that yes, indeed somebody can do these things because they know how to do them. Unfortunately, human behavior being what it is, it's not always that straightforward. And so what I wanna do here, it may seem like a little bit of a digression, but I hope you'll bear with me because it's gonna shed a little bit of light on the nature of the challenge of duration estimates. And at the same time, I hope what you do is take this information and start applying it a little bit in your own situation, so that when you are asked to come up with duration estimates for a project you are working on, or when you're asking other people who are working for you to come up with estimates for how long their activities are likely to take. One of the things that I want you to be cognizant of is the fact that it's oftentimes not as simple or as cut and dried as we think it is to get people to give us what we would call an accurate estimate, and there's some reasons for that. And I should paraphrase by saying, there's some fairly understandable reasons for it. It's not as if there's deliberate deception going on here. There's some things that are taking place. So with that being said, let's explore some of the ways in which people have this power to distort duration estimates. And so what I wanna do is walk us through three basic common mistakes in duration estimation. And you see them on the screen here in front of you that they're listed basically, we have these ideas of padding estimates, what I call the new math, and third anticipating top management cuts and the implications of what that might lead to. So I want to talk about these in turn because these are three very common ways in which what we think of is a straightforward deterministic estimate, can actually get turned on its ear if we're not careful. Let's take the first one, padding estimates. If you see in front of you here, this, a very interesting curve. This curve is referred to sometimes as a Gaussian or log normal distribution. Notice this is very different than your standard normal bell curve that we think of in most probability in statistics classes. This one has a very different implication to it. Look at the percentage likelihoods there across the top 25%, 50%, 80%, 90% as it progresses. What I want you to think about with this curve is that when I ask somebody who works for me how long an activity is likely to take them, one of the implicit underlying questions that they're really trying to factor in here, filter out of my request of them, is, "What estimate am I comfortable giving my boss that is still going to leave me with a real likelihood that I will get it done?" Let me say it another way. If you were asked how long it would take you to do an activity, would you feel comfortable giving your boss a 50/50 likelihood? In other words, "I may hit that number, I may miss it." For most of us, the answer is no. We wouldn't feel comfortable. We'd be afraid that the boss would look down on us. We'd be afraid of all kinds of ramifications for missing that number. So I ask my students in class this question, or I ask my master's students this. I said, "All right, you tell me. Give me a probability that you would be comfortable going to your boss with?" And they scratch their head for a moment, and then the general reaction is, well, 90% probability some will say even 95% probability. So they want to come up with something that is a much safer estimate for them. And on one level that's fair. I understand their point. But look at our curve again, when we talk about it in those terms, you see a very interesting phenomenon. You see what this log normal estimate suggests is this, you see the 50% likelihood point right there. Now, in simple terms, what this is telling us is, if I have a five day estimate for an activity that I'm gonna be performing that's the 50/50 likelihood. It should take five days. Can I be a little bit early? Of course, so it may be likely that I could actually finish it a day early. But what's more interesting is look at that long tail that's stretching out to the right. And you'll see that's really the story of the Gaussian distribution. It's not the fact that I may be able to finish early, because if I do I might finish maybe one day early, possibly two, but that would be a stretch. But you notice from the other direction, I could finish very, very late. So that five days could stretch out into 10 or even 15 or longer depending upon disruptions, depending upon who else bugs me, while I'm trying to work on your project, depending upon how many different balls I'm juggling at the same time. So, five-day estimates may or may not hit, they may be early, but you can see from that curve they could be incredibly later. Now let's flip that on the other side. So remember I just said a minute ago if you were asked what is the likelihood that you would be comfortable giving your boss quoting them a duration, and you say 90%, we'll see what that does to the estimate for the time. See, the 50% is my five day estimate, remember? But now if we're talking about 90% estimates it may not be five days. In fact, it's looking like it might be 10 or 12 days. Just because I'm trying to protect myself. I'm trying to give myself a little extra time so that I feel most comfortable with that estimate I give you. Now, the moral of the story here, when you're running projects, is not to automatically cast suspicion on your subordinates. In other words, the minute they say, "Here's how long this is gonna take." You immediately think, "Aha, this person's lying to me 'cause he's patting his estimate because he wants to make sure that he gets it done within a 90 percentile." Part of your challenge is to recognize that the person is doing this because they want to give you an accurate estimate. They wanna make sure that if I say 12 days that's gonna gimme a 90% chance of getting it done. Five days is probably reasonable but I want to be sure how do you combat that? Well, one way you can combat that is, first of all by lowering their personal risk. You have to make it clear to these folks that what you're looking for here is not them padding in or adding a whole bunch of safety to their estimates just to protect themselves. Your job essentially is sort of nuclear disarmament. I'll lay down my weapons, you lay down yours. I will not sanction you if you're a little bit late. But the flip side is you have to be honest with the estimates you're giving me. You see the two of us have to work this mutually where there has to be a level of trust between us so that my subordinates when they give me a cost or a duration estimate are giving me the honest best guess they have which is probably gonna be much more around the 50/50 likelihood. Now think what that means. They may make it, they may miss it, but your part of the deal as the project manager is to recognize if they're gonna be honest with you with their estimate you have to be honest with them in terms of protecting them if something does happen. So padding estimates, and those estimates then can run much, much longer than what we might consider to be a normal type of duration, something that really should be the case. We're not done. You see, that's only the first problem because the second problem doesn't necessarily occur with the subordinate. This may occur with you, the project manager, if you're not careful about it because you and I can very easily fall into this same trap, only one level removed. And it goes... I use the term the new math which I know you were probably puzzling about. So let me explain the new math to you. The new math works like this, two plus two plus two equals eight. And you're probably thinking, "What am I talking about." Well, let me explain. Imagine you are that project manager again, and you have three people working for you, John, Ted, and Carol. You ask each of them to do a specific activity related to the project and they all have to get their stuff done working for you. So John says, "My activity's gonna take two days." Ted says, "And my activity's gonna take two days." Carol says, "My activity's gonna take two days." So, you take that information, but remember you're also thinking about self-protection and you're thinking, "Well, what if they don't get it done in two days?" And so you add in your own margin of safety here to get take that two plus two plus two plus a little extra just to cover yourself. And magically those three estimates have added up to eight days instead of the two each. Here's the irony. Think what we just talked about in the first point there, if I don't have a trust-based relationship with those subordinates in the first place, each one of those two day estimates has probably already been padded. So you see what you're doing here is without really thinking this through, you're taking padded estimates and you're adding some additional safety on top of that to cover yourself. And all of a sudden we've gone from padded two-day, padded two-day, padded two-day, to an ultra padded eight days. Just because we're trying to protect ourselves. The same solution set applies here that applied in the first situation. When I'm asking my subordinates for honest estimates I have to respect the honesty of that estimate. And I have to understand that the more I build into this plan, actually, is only going to create a very biased, a very over bloated plan that I'm trying to find ways to cover with smoke and mirrors instead of looking at the honest estimates, I should be doing. But you see, unfortunately, we're not done because that's only two of the problems that occur and there is still a third one. And this one we can lay very directly at the feet of top management because what happens many times is that I have top managers who operate under the notion that motivation only occurs through pressure. So the more that I pressure my folks, the more that I keep their nose to the grindstone, the more motivated they are. And therefore, the way some of these top managers have hit on this is a very novel, I think a very self-defeating idea, but a very novel idea, that says, "No matter what estimate you're going to give me, I'm going to shave a percentage off it. I'm going to just assume automatically that it's 20% inflated or 30% inflated or maybe more. So the minute I get your project plan, I get those duration estimates from you, I'm going to shave 20% off of everything." Well, think about the death spiral we've just put ourselves in from a trust perspective here because very quickly people in the organization pick up on what top management is doing, and they know, that these cuts are gonna be coming to their plans. And so what do they do about it? Of course, they simply rejigger their plans to take into effect those anticipated cuts. And lo and behold, let's say the plan that you created painstakingly and you created your network activity chart, you created all these duration estimates, you put it all together. And as we're gonna show in this lesson you've determined how long the project should be. Let's say you discovered that that project should take about 80 days to finish but you know you have a boss who's going to shave 20%. So that 80 days that you created, you're automatically going to create a real new project plan that's inflated this out to 100 days for no other reason except because you know he's gonna come back in and shave 20%. And the weird thing about this is you know this boss is gonna do it. This boss knows that you're anticipating these cuts. And so neither party is playing honestly with the other party. And what's happened is the idea of a deterministic estimate, the idea of a estimate that is supposed be based on values that we know is being miraculously, or maybe un-miraculously distorted because we don't trust each other. I had a project manager when I was first starting out, and he had forgotten more project management than perhaps I'll ever know. He knew the book inside and out. And he said to me, something, one day that I've never forgotten all these years later. You can see it there on the screen. He said, "Pinto, one thing I know in this business is if you don't take my estimates seriously, I'm not gonna give you serious estimates." "If you stop taking my estimates seriously, that's the day I stop trying to give you serious estimates." The two of us now are no longer trying to be honest with each other. We're simply in this mutual battle of self protection. So you see on the surface, the idea of deterministic estimates is a very good one. And is certainly is a very valuable idea. It says basically that we can know how long the activity durations should last. We should be able to know that. The problem is that under the circumstances here if we allow all these behavioral issues to pop in, if we start padding our estimates, if we start employing the new math, if we start padding further to anticipate top management cuts, we can come up with an extremely bloated schedule that instead, of being an honest, let's say 30 days to complete this project can be a dishonest, but self protecting, 120 days. Don't forget though, that the longer and further out you've had your estimates the more top management will start catching on with this. And we simply perpetuate the same cycle of distrust. So, deterministic estimates is a great move, if we can do it but let's be mindful of the negative ramifications depending upon the culture of our organization and the degree to which we trust our subordinates and they trust us. Now, there's a second duration estimation method that's also quite common. And this works under a concept known as the Program Evaluation and Review Technique. all also called PERT. PERT was developed back in the 1950s. This is a way that the US Navy, when they were first coming up with their Polaris missile programs, they were in a bind, because they were coming up with a brand new technology and a brand new setting, that was cutting-edge, that was gonna involve a lot of new scientific breakthroughs. And they were trying to put together a schedule. They were trying to put together some notion of an activity network and how long these activities should take. And they didn't know. Because it was all leading, cutting-edge technology. And so, there was very little way that they could factor in exactly how long it would take. So they were forced to fall back on the idea of probabilities. Since we don't know how long these estimates are or we don't know how long the durations are likely to be we have to use probabilities to estimate how long they're gonna be. So PERT, was created with this alternative idea that said, "We're going to now use a mathematical derivation." Relatively straightforward, but a mathematical derivation that will allow us to determine how long these activities are most likely to take. Is it exact science? Absolutely not. It's giving us a better guess though, of how long things should take because of mathematical likelihoods. And so what I ask my people is to generate for me three values. I want them to estimate for me what's the most likely amount of time it should take to complete this activity? What's your most pessimistic estimate? And if all the stars align and everything happens according to plan, what's your most optimistic estimate? So most likely, pessimistic, and optimistic, we have those three values and we use those to insert them into a basic formula which looks like this, activity duration, time estimate here is the most optimistic plus four times the most likely, plus your pessimistic estimate divided by six. So most optimistic, most likely times four, pessimistic, take those, divide that number by six. That's gonna give us a probability estimate within six standard deviations. In other words, about 95% a likelihood. And that's something that we can live with. So how does this work? Let's take an example. Suppose that I have a setup like this, where I have the activities that I've identified that are gonna take place, my tasks, I identified the predecessors but more importantly now I've added in a little bit more information because in the last lesson all we needed was the task and the predecessors and we could create our network diagram. Now though, we want to flesh this out some more. So let's suppose that we have our A plus B, plus C, where in this case, A is going to be the most optimistic, B is the most likely, and C is the most pessimistic. Now notice one thing about that list. Do you see here, how for some of these values, the most likely... Let's take Z, the most likely is eight days. The most optimistic is maybe we can shave one day off of that estimate. But you notice here, for the most pessimistic this could actually run out almost 200%. So, we could double this out to 15 days from the original estimate, the most likely of eight. So if you look at this, you can see this is just based on an illustration, but it's trying to make the point that in some cases, the worst case scenario can be significantly bad. Now, when we have this information so we've done a fair, good faith effort to come up with our most likely, our pessimistic and our optimistic, we can simply determine the expected duration of each one of these activities. And we do it using that formula. You can see here that following through with this Z is the expected duration should be nine days, Y should be 16, X should be 18, and so on. And S there, we could round that down to 14, but you get the idea. Basically, this is telling us that these are duration estimates now, not based on deterministic values but based on a series of probabilities. What's the most likely thing that's going to happen under these circumstances?