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

<v ->The third reason, lemme be honest,</v> this third reason is going to bother some of you listening to me. Some of you are going to flat out reject it and that's okay, that's fair. Some of you are gonna say this doesn't really happen to my organization, that's fair as well, I'm not suggesting, if you remember at the beginning of this presentation, I suggested, not every one of these problems is going to pop up in every organization. Some of you may find experience of this, some of you may relate to it, some of you simply will not, and that's okay. So, in posing my third reason, I fully recognize that this is something for which some of us and some of our organizations are prone and for others it simply is not an issue. And if that is the case in your organization, great, then this is not something we have to worry about. But for the others, the idea positive variance means that I finish early. Positive variance means I got it done ahead of time. And so that raises an interesting question, what happens in your organization when you finish an activity early? Remember, you said that it was gonna take you 15 days to get something done, you got it done in 13 days, everything worked the way you wanted to and you got it finished in 13 days, you saved two days on that. The question I'm asking is, what do you do with that time? What happens if you finish early? And the answer in many organizations is perhaps it's not what you'd hoped would happen. Now, I can be a little bit facetious here and I can use this expression, I can say no good deed ever goes unpunished but lemme explain what I'm talking about. In some organizations where there's a lack of authenticity, and that's an important word, authenticity, authentic communications between you and the boss. When the boss, the project manager, gives you an assignment and asks, how long will this take? Well, remember we've already talked about this, we tend to add in our personal safety here, so, I'm gonna inflate this a little bit. But let's just say for the sake of argument that I give this boss an estimate of five days. The boss says, okay, fine. Let's say further that I finished this in three days. The question becomes what do I do with those two additional days? Remember I promised it in five, I got it done in three, do I present it to the boss after three days? Well, the short answer is, it depends. And you know the answer to this better than I do, it depends on your organization. Are there actually sanctions for getting it done early? Now by that I don't mean that you literally get punished but think about the long-term sanctions. Suppose I'm thinking about this, I turn it in after three days, two days early. A month later, the boss asked me to do another activity, how long will it take you? And I do an honest job, I look it over and I say, boss, it's gonna take about five days. And the boss gets back to me and says, wait a minute, you told me five days last time and you got it done in three days so, why can't you get this one done in three days? And you see what's just occurred here is I tried to be the good soldier, I tried to present this to him in three days only to be told as a result of that, I don't trust you, I don't trust your estimates for next time. That's why I say no good deed ever goes unpunished in some organizations, I don't wanna say in many organizations, I don't wanna propose that this is a universal law, I simply wanna ask us, sitting here listening to this, I want to ask each one of us consider your own organization and ask the honest question, does positive variance get passed along? Is it incumbent upon me? Is it appropriate for me? Is it safe for me to turn in activities that I complete early and have no problems with that? Or is it likely to actually boomerang and become a negative issue? Only you can answer that question. But we have to acknowledge that in organizations out there, this is a relatively depressingly common phenomenon and it speaks to the fact that you and I, the project manager and the boss do not share an authentic communication with each other. You don't trust me and as a result of that, I'm not gonna trust you. The term goes something like this, if you don't take my estimate seriously, I'm not gonna give you serious estimates. If you don't take my estimate seriously, I'm not going to give you serious estimates. Now, ladies and gentlemen of the jury, we're not done yet, I have some more evidence to present to you. Another reason why we lose all that safety time that we work so hard to build into our activities is the result of multitasking. You know what multitasking is, right? We all do, this is where I have multiple activities for which I'm responsible all at the same point in time. And so I may have three, four, five projects that I'm contributing to. I have students in my classes and I asked this question, how many assignments do you currently have outstanding? The record I have is with one person he was in a software organization, he told me he had 23 activities that he was currently trying to satisfy different people, 23 different opened responsibilities that he hadn't closed off yet, that he was still trying to juggle. And so what happens in those situations is exactly that. When I am multitasking, I've got this problem of juggling, I'm trying to keep all these balls in the air and in juggling all these balls, think what that does to the overall duration of those activities. Lemme illustrate, look on the screen here. Suppose we have a very simple situation, there's three activities each one of them is 10 days duration. So if you just left me alone to do them one at a time, it would take me 10 days to get A done, then 10 days for B, then 10 days for C. But I don't have that luxury because I need to be showing progress on each one of these. Remember the juggling? And so I'm juggling these, I'm trying to show progress and so instead of a simple model like this, here's what it ultimately looks like, I work, let's just say, again, a simple example, I work five days on activity A, then I'm feeling pressured so I have to shift to B, then I'm feeling pressured to go to C, then back to A et cetera. Notice what this does. This simple example of only three activities, notice what this does to the actual duration of each one of them. It doubles it. Activity A now takes 20 days to finish whereas before it would've taken me 10 days to get done, now it's taken 20 for no other reason than the fact that I'm trying to juggle balls. And now if you're listening to me and you're being a little bit critical about this, you could raise another point. You could say, but wait a minute, that's not really accurate because what you have here is assuming that I can just shift from activity A to B to C with no downtime. And you're absolutely right, so let's think about that a second. Suppose we factor in learning curves, we talked about learning curves. Suppose we factor in the learning curve and so now we have a situation where when I finish A, it takes me a day or two to ramp up to activity B, and then I work on B for five days and then I put that aside and it takes me a day or two to ramp up to activity C, et cetera. And on it goes and you can see it may not be 20 days to finish activity A, it may be 25 days or some other number as well. But the point is, that multitasking extends activity durations and you know how much multitasking you're responsible for. And as a result of that, I submit, ladies and gentlemen, you and I, one of the reasons we create those activity estimates with that margin of safety built into it is not simply for the 90% likelihood of completing it but also it reflects the fact that I'm very busy and I have a lot of balls in the air and I have a lot of responsibilities and a lot of people banging on me to get work done for them. And in that situation is it any wonder that I want to add some safety to each one of those activities because I'm so multitasked? So what can we conclude? Well, lemme remind us of the roles we're playing here. You folks listening to me are the ladies and gentlemen of a jury and I've been presenting two opposing points of view. I'm presenting a case on one hand it was no project should ever finish late and I gave you the reasons why that should be the case, and as the alternative attorney, I've now taken, I believe, each one of those arguments and one by one demolished them, demolish the foundations on which they stand to recognize that, yes, do we tend to try in fact build in a margin of safety with those activity duration estimates? Probably and quite probably understandably as well. At the same time, what do we do with that? Well, we make a series of mistakes. Some of them are our own, some are the result of the way the project schedule is set up, some of them are the result of all the project activities I'm responsible for, multitasking, much of it is the result of an inability to create an authentic communication base with my manager or alternatively, if I'm the project manager, to be authentic with my subordinates. And so what we do is we do this to protect ourselves and so self-protection is evident at every step of the process. So what can we conclude? We talked in an earlier lesson in this course about the mechanics of scheduling and the process of scheduling. And I am not for one moment trying to minimize the value of those steps and the importance of those steps and the necessity of creating a viable coherent schedule, it's critical to projects. But please, please, as I say here in this first bullet point, these mechanical elements and scheduling are necessary, but they're not by themselves sufficient, they're a necessary but not sufficient condition for understanding how scheduling is going to operate in projects, my projects and your projects. When trying to do that, we can never discount the human element, what I call the behavioral side of scheduling for a purpose because it's all about people. And many of the causes of project overruns are related to unhealthy project cultures, unhealthy organization reward systems, weird managers, weird subordinates, stuff out there that goes beyond the strictly mechanical steps in creating a project but we have to recognize maybe, maybe the case in our organizations and make the appropriate allowances for that. The third point is to recognize that many of the steps that we think we're taking to fix a project is only spinning it further out of control. Brooks law is a reasonable way to recognize the importance of a learning curve and the fact that adding resources to ongoing activities is not a viable solution. Working overtime sounds good because it seems to our superiors that we're doing the necessary things to get the project back on track but generally speaking, it doesn't work either. Many of these steps, they sound good on paper, they work very poorly in practice. And as I say here, my concluding point is recognizing that authentic communications, authentic leadership, acknowledging reasonable alternatives when it comes to duration estimates is necessary for me as the subordinate to disarm, 'cause that's what it is, isn't it? If I'm going to give you an honest estimate, I have to be treated that I'm giving you an honest estimate, you can't sanction me if I miss it. A 50/50 estimate means just that, it's 50% likelihood. But we have to get to that point, you and I have to understand and as a project manager, you have to understand are your subordinates in self-preservation mode because of the last project manager who they worked for or because of some other reason? And you have to find a way to get beyond that, and the key is being honest and authentic with each other because at that point that those project schedules we created in that earlier lesson can actually run the way they're expected to run without the impact of these behavioral issues. Thank you.