9.1 Understand what is meant by the behavioral side of scheduling - Video Tutorials & Practice Problems

<v ->Welcome to Lesson 9 with a rather intriguing title,</v> The Behavioral Side of Scheduling. You've taken a lesson and looked at scheduling dynamics, methods for activity, duration estimation, determining the predecessor relationships, letting the computer if necessary determine for you the critical path, but we talked about how that would be determined, how activity slack is determined. We've looked at the process of scheduling from a relatively tools based point of view. In other words, we have some very useful dynamic sets of tools that allow us to come up with a project schedule determining how long an activity is likely to be, how long the project as a result is likely to be. So in Lesson 9, what I'm gonna do here is I'm going to take a side trip if you will, and I want to talk about scheduling, but I want to talk about it now from not the tool based side, I want to talk about it from the human side. And that's why I came up with this title, The Behavioral Side of Scheduling, which as I said, should sound intriguing to us a little bit. And what I want to do is I want to propose a series of potential potholes that we need to be mindful of, things that we need to be aware of so that we can avoid them when it comes to project scheduling. Now, in this lesson, I'm going to be proposing a series of problems that can happen as a result of human beings being involved in the scheduling process. Please bear into following things in mind. Number one, these are potential warning signs. They're not absolute laws. In other words, it's not necessarily the case that each person listening to this is subject to this particular problem or that their organization is rife with these issues. For some of us, they may not necessarily apply, and if that's the case, that's fine. I'm not suggesting that every one of these problems with scheduling is going to occur to each one of us because one thing we know about human beings is we're incredibly complex, and therefore, what affects one of us may completely not affect others and vice versa. So bear this in mind. These are not laws. They're simply guidelines, things to look out for. The second thing is I ask you at the outset is to be open to these issues, be honest in your own self-assessment of these issues. Do you have a tendency potentially to err in certain ways when it comes to these aspects of scheduling? That's fine, if that's the case, the point is to be open at least to the acknowledgement that you or your organization may have issues that you have to deal with here. In saying this then what I'd like to do is I would like to set this up a little bit in a sort of different way. I want to pretend for a moment that you and I are in a courtroom. You are members of a jury and I am the attorney, actually I'm gonna be the attorney on both sides so I'm gonna present both arguments. But I want you to try as much as possible to treat my arguments as if you were listening to a presentation by an attorney in a jury trial, and you're sitting in the jury, and you're listening, and you're trying to form a judgment. And so that's your role. My role, as I said is to be the attorney representing these two alternative sides of this argument that I'm gonna make. And the argument I'm gonna make is a rather interesting one because here's where it is. I call it a modest proposal. My modest proposal is no project should ever finish late. Now, I know what you're thinking. Those of you who work in a project organization are immediately objecting to what you've just read because you're thinking yourself, "Wait a minute, I have projects that finish late all the time. I could name you five projects I've been involved in just in the last year that have finished late", or et cetera, et cetera. In other words, this is something that you naturally react to when you see this on the screen. But listen to me a minute. Remember what I said here? I never said, "No project will ever finish late." What I'm saying is, "No project should ever finish late." That's a bold statement, but I'm gonna try to back this up. I'm gonna try and present evidence to you as an objective member of the jury, and please try and be a subjective in hearing this as possible. I'm gonna present evidence as to why no project should ever finish late.