9.3 Understand the ways we waste project safety (Part 1) - Video Tutorials & Practice Problems

<v ->So now</v> I'm the other attorney. I'm playing both roles. So now I'm the second attorney, and I stand up, and I say, ladies and gentlemen, you've heard a compelling case on the part of my colleague here about why no project should ever finish late. And he does paint an interesting portrait of organizations that contain members who are loathe to give you a 50/50 estimate, who have bosses that have their own safety margin. And also anticipating top management's cuts, we have a lot of extra schedule time floating around in the system, and he's painted a good portrait of what the implications of that are. And I would agree with him that if this were the only bit of evidence that he saw, and if this was the only material that you witnessed as the jury, I would agree with him that it's clear that that's your verdict should be that no project should ever finish late, but he's wrong, and he's wrong, because he's missing out on a very important piece of information which I'm gonna elaborate on now. The fact of the matter is projects still finish late, because we are equally good at squandering that safety time that we were so meticulous about acquiring. Let me say that again. We did a very nice job of setting ourselves up with extra safety time in our project activities, but then we turn around, and we waste it. And I wanna explain in my presentation where that extra safety goes. And I want to ask each one of us in what sense am I capable? I'm not saying culpable. I'm not saying we do it, but what I am asking us is to evaluate this. "Am I capable of making these mistakes? Does my organization promote this? Do our reward systems promote it? Is there a dynamic or a culture in place that encourages this kind of behavior?" So with that being said, let's look at the reasons why we lose all of that time that we so preciously acquired. The first reason is something that I call the term paper model. Now, do we remember this from college? Remember in college, when you were assigned a term paper at the beginning of the semester, that wasn't a big deal. I mean, you knew a term paper was coming. You knew we had 14 weeks in the semester. And so the assignment is given to me, and I look it over, and it's not a big deal, and I don't think too much of it. And time elapses, and you'll notice on the X-axis here is the percentage of time elapsed. We start over on the left side, and 50% and finally a hundred percent of the time elapsed. The more interesting though is the Y-axis, because that's percentage of the project completed, or let's say the activity completed. So let's drill this down to the specific activity that you are responsible for. So time and percentage of the activity. Now you see there on the screen that the perfect world model would be one where we follow this precisely. So at the 50% point in the class, seven weeks into the class, I've done 50% of my term paper. 75% of the way through the class, I'm 75% done, and a hundred percent of the way, boom, I turn it in. Logically that would make sense. That would be the perfect world model, right? But let's remember our own experiences in college. Did we ever do that? No. No, the term paper sat, and it sat empty. Maybe I looked at it. Maybe I checked a book out of the library. Maybe I got on Google, and I did a couple quick searches or something, but it was 14 weeks out. Why worry about it now? And so in fact, that's exactly what would occur. We would just put it off and put it off and put it off. And so what you see here now is instead of the perfect world, the learning curve or the term paper model, either one, is this sloping line that shows that about 50% of the way through the class, seven weeks into the semester, have you done much work at this point? No. You've done a little bit. You've started doing a little nibbles around the edge, but you really haven't put a lot of time into it. And the really interesting irony is, and I've experienced this both when I was involved in projects and as a professor at a university, so I've seen this on both sides, and it still applies. Right around the point where the panic hits is right around the maximum difference between where you should be, and you know you should be, and where you actually are. So if you look on that model, and you see this point where there's the biggest spread between the curve and the perfect world, this is when panic occurs. Now when panic occurs, what happens is that my students knock on my door, and my subordinates used to do this. And what they want me to do is they want me to push out the wall. You see the wall there? The wall is exactly what it sounds like. This is the deadline. I expect this done by this date. That's the hundred percent of time elapsed. That's the wall. I want it. And students come to me, and they basically say, "I need more time. Basically what I need is I need you to push out that wall." And what I tell them is something that goes like this, and I'm not being facetious when I say this. I'm saying that basically "I'm gonna do you a favor. No." Now, you can imagine students walk out of my office mumbling under their breath, "Some favor. Thanks a lot." But let's be honest. Let's think about our own experiences with this. Do you see how the term paper model, the curve there, starts ramping up dramatically? This is very common, because at some point, when the panic sets in, or when I realize that the due date is looming, and I need to get this done, I start rapidly ramping up the work. I start working on it like crazy. Just like our term papers in college, folks, and in organizations it's very similar. I set all the other stuff aside that has been distracting me, or that I'm committed to, and I start working fully on this activity. So in other words, what I tell students is, "I'm gonna do you a favor. I am not going to push out the wall." They want to. But if you think about your own experiences, suppose you came to me and said, "I need two more weeks." And I said, "Okay, fine." Have you really learned your lesson? You walk outta my office, and boy, it's the straight and narrow for you now. Probably not. In fact, for many times, this is just a stay of execution, isn't it? The reality is that I've been let off the hook. Now I can go and do the other things that were piled up, and eventually I'll get to this. But you see, I haven't learned a lesson. So the problem with pushing out the wall is, number one, it lengthens the duration, 'cause remember I gave you whatever the duration was, I gave you that time to do this, and now you want more time. Or I'm just recognizing the fact that this has to get done, and there's gonna be a ramp-up involved in it. Pushing out the wall doesn't improve the process. It simply delays the completion of the activity. So that raises an interesting question, doesn't it? The employees' solution is to push out the wall. Bosses, however, when faced with this crisis, bosses have a couple other solutions. See, bosses aren't blameless in this. We also have some tendencies when it comes to solutions about problems with the wall looming and a seemingly late activity. And we can do one of two things. And I've seen very common in both of these situations. So what I want do is I wanna break down the boss's solution here, and I wanna suggest that these are two more very bad ideas. The employee, my subordinate, wants me to push out the wall. I don't wanna push out the wall, but I do see that there's a problem here. So I've got my own cards to play. Now, the first card that I play, and this is a very common one, and we've seen this in our organizations, is let's add resources to this activity. You're late, I'm gonna give you a couple new people. "Joe and Carol, you guys go and help them." We've seen that a lot. Second, let's work longer hours. So let's throw in some overtime. Let's make sure we get it done. So we'll just put in a few extra hours this week, and we'll solve the problem. Let's talk about these both. I'm gonna suggest that these are two really, really bad ideas. They're common. They happen a lot, but they're not good alternatives. And I want to go through each one of them and explain exactly why that's the case. So let's start with the first one. Let's add resources to the activity, right? Well, here's a problem. The problem has a name. Problem has a person's name, a guy named Fred Brooks. But the problem itself is called Brook's Law. Now I have to explain this. Fred Brooks was the project manager for the most successful family of mainframe computers ever developed in the world. Now, that's a bold statement, and for some of us, we don't even know what a mainframe computer is. This is just talking about the dim and distant past. And you're right. IBM, at one time the world's leader in developing these massive computers, okay? Now I'm not saying that they were better than an ordinary PC in terms of their abilities, but remember, we're talking about the 1960s. So we're talking about a time that was many, many years ago. And in that circumstance, IBM was the world leader in these massive computers called mainframes. And in the 1960s, they introduced a brand new family of mainframe computers, the IBM 360 series. Fred Brooks was the project manager for the operating system for the IBM 360 series of computers. In developing the operating system, his project was over a year late and millions of dollars over budget. And after the fact, after the fact, he looked at this, and he thought to himself, "Why did this occur? Why are we behind time? Why did we lose all that time?" And he formulated something called Brook's Law that I wanna share with you. Brook's Law says adding resources to ongoing activities only delays them further. Let me say that again. You see it on the screen, but let me just articulate that point again, because it's very counterintuitive until we think about this. Adding resources to ongoing, to current activities that are running late, is only going to delay them further. And as evidence, he cited some interesting points. He said let's take an example. Suppose I have five people working on an activity, and it's getting late, and I get worried about it. So I add two additional people to that project team. Well, the practical effect of that is to take this person and this person away from the work to train these two. So now I actually am down to three people working on that activity, because these two people are training these two people. And as the boss now, I get further behind, as the boss I panic a bit more. So let's add two more people. Well, you guessed it. Two additional people takes two others out of the actual activity work to train them. And now I've got one lone person who's doing the work, while these other four are training these four. And the net effect of all this is to delay the project much, much further, because I tried to add resources while this activity was ongoing. This is a learning curve effect, folks. Why are these people taken out of the loop? Because they have to teach these people. They have to get them up to speed. And until they can reach the learning curve, we have this problem associated with it. So we are concerned about taking people off of activities, because they've lost the learning curve to train other people. Learning curve is a very common function in organizations, in projects. For example, Boeing is very big on using learning curves, when it comes to determining the duration of activities, how long things are supposed to take, how much time it's gonna take for the first cycle versus the 20th cycle. Builders do this as well. So a builder can say, "Look, for the first support structures on this bridge, it will take 20 hours to get the work done. But by the time we've done it seven times, we can get that down to 12 hours." Why? Because they've learned how to speed up the process to become more efficient at it. But it works in reverse as well. So my five people who were working on this activity, yes, they were delayed, but they at least they were up to speed now, and they were working on it, are now losing in effect those four people and the learning that they had, just to bring them up to speed. So that raises a good question. The question is what do we do about this? If the activity's delayed, and my knee-jerk response is to throw more resources at it, and you're just showing me from Brook's Law that this is not the solution, what is a solution here? And it's a fair question. So let me propose an alternative solution. And this solution, folks, remember, is predicated on the fact that you are the project manager. Now, I can't emphasize this point enough, so please hear me. As the project manager, you are in a unique situation. You see the overall project. You have the project laid out in front of you. You have the 10,000-foot view. Some of your subordinates may not have it, may not want it. They're not really concerned about it. They're concerned about getting their task done, but you have a much broader expanse. And so for you, you can look at the overall project. And so, notice what I've put on the screen here. What I have here is a simple project plan. And let's say for example, that we know that B, that activity B, is running late, and we know further that it may in fact be late. There may be nothing we can do, even with the learning curve model that I showed you before, where in our term papers, we ramped up and got 'em done in time, even if we were really gasping for air by the time we finished. Sometimes that's simply not the case. It is going to be late. But if that's the case, adding resources to activity B while it's still going on is not the correct move. The correct move, as you can see here, I call it attacking downstream, which is simply a way of saying that if I'm gonna add resources, that may not be a bad move. Resources may in fact speed up the project, but not at the point of the ongoing activity. Add resources where they can do the most good, which is somewhere downstream, rather than at the point where the project is running late. That's called attacking downstream. And that's one of those things that we have to recognize as a project manager, have a unique perspective, where I can identify the activities that are running late, but I can also identify subsequent activities, where I have the best opportunity to apply resources to get us back on track at a later point. Does activity B finishing late torpedo our project? Probably not. But it does make me now think, "If this is gonna be late, what are my points of remediation? Where can I fix these problems at a later point downstream, so that the project can get back on track?" Okay, that's the net effect of adding resources. Simply adding resources to ongoing activities will not work. Brook's Law shows this. We wanna do it, because it sounds like a smart move as a project manager to show that I'm on top of things, but it's not an effective move. Well, there's another option. We can always work more, right? We can assign people to work overtime. And we see this as well. You see this in your organizations. I see this in mine. Now at a university, I talk to some of my students in my classes and I ask them, "How long is your day?" And their answer is interesting. The answer is, "I work until the work is done." "When's the work done?" "Well, it's never done by five. It's until six or whatever. I stay there until I have to get the work done." So we're sort of used to this model of working until the work is completed, and that falls into the whole overtime business. It's like keep working until we get it done. But again, as with our issue of adding resources to ongoing activities, there's a problem with this mindset. Research has looked at this, folks. Take a look at what you see in front of you. Ken Cooper did a study of looking at the real effect of overtime hours. And he found, and he looked at it with two different disciplinary groups. He looked at it with production personnel and with engineering staff. And boy, did he find something interesting here. He said, now this is just overtime hours per week, not per day. This is over the course of an entire week. And he found that if you assign people overtime to the tune of about four hours in a week, you might get, if you're engineering staff, you might get about one and a half hours of real additional activity out of that. So think about that. Four hours of additional overtime can lead to about one and a half hours of actual productivity. Eight hours of overtime led to almost nothing, just barely positive result. And 12 hours of overtime actually resulted in the loss of one hour of output. Why? Fatigue. The need for rework. Because the more hours that we require our people to work the more mistakes they make, and the more mistakes they make means we have to go back after the fact and look and see what occurred there. And that usually means rework. And so according to Cooper, and his study was done with hundreds, if not thousands of projects that he was involved in. Ken Cooper was a very well-known consultant at the time the did this study. And so he had access to databases of massive numbers of projects. And this was the net effect. We kid ourselves, if we think working overtime is actually a solution to the problem. In fact, as you can see here, working overtime becomes a deeper problem on top of the original one. So ladies and gentlemen of the jury, my first bit of evidence, as to why we squander our time is the term paper model. My second bit of evidence has to do with our responses to the term paper model, our responses to the need to ramp up activities. Employees want me to push out the wall. I've suggested why that's not a good move. Project managers adopt two equally poor decisions, throwing extra resources and working harder. Neither of them generates the returns we would hope that they would. In fact, they can complicate things further and make the project fall further behind. So that's my first bit of evidence. So ladies and gentlemen, let me present a second piece of evidence. I call this the problem of merging paths. Notice we have three paths in our project, and they're all merging at this point. Path A is 15 days late. Path B is right on schedule, well done. Path C is 15 days ahead of schedule. Even better, even more well done. That looks like that's probably good news, doesn't it? But the reality is no. Some of you can see this immediately, and you see, no, because the overall project moving forward is dependent upon the worst previous performer. In fact, path A. If path A is 15 days late, it doesn't matter what happened on those other two paths. We have a problem. All it takes is one path being late, and any future activities are gonna be late as a result. Now, in fairness, I would not say that this is a behavioral problem, per se. So just putting it out there that when we talk about human error in scheduling, this isn't really the same, or it doesn't qualify quite the same. This is more a structural error. Sure, you could say, "Well, it's an error, because path A is 15 days late." And I would agree with you, but in general, we think of this more as a structural problem. I created a merge point of three paths, and in doing that, I made my project dependent upon, not the best performer, but the worst performer. And so those three paths ultimately mean that the overall project now is 15 days delayed.