4.1 Employ multiple elements in project planning and scheduling - Video Tutorials & Practice Problems

<v ->Well, this lesson constitutes the start of,</v> in many ways what people would think of as really the meat of the project management challenge. And that is taking a lot of ideas and a lot of creativity and a lot of hopes and dreams and converting them into something that can actually be realized. In fact, in many ways, the challenge that you're gonna face in project management is being the expert in your organization and doing precisely what it is we're gonna be talking about now. And that is operationalizing these ideas, because up until now, even creating scope and creating the genesis of what we're attempting to do with this project, a service project, a new product development project, it doesn't matter. The idea is a good one, and it's powerful because it triggers what's gonna happen after that. But what's missing is some ability to take and create a rational pathway from the idea to its natural fruition. In other words, making it happen. Your ability to be the one person in your organization or the one person in your department who can make these things happen is going to create an enormous amount of career value for you, because you're going to have a mindset, a discipline base and a thought process that's going to allow you to convert, to create, to proceed. And that's what this section is about. We're gonna be talking about creating the project network now, as we mentioned. And what does that really consist of? Well the first thing I want to do is reintroduce our old friend. If you remember our lesson two on scope management, I went to some length explaining the idea of the work breakdown structure. And if you remember what I was doing, I was trying to give us an overview of the value that a work breakdown structure has for us. The WBS is our means to take that project and deconstruct it further down, further down, further down, until we finally get to an activity level. And those activities are what we are going to be focusing on and what we're going to be pushing, creating, developing, because all of those jointly and collectively, then ultimately work backwards up the hierarchy, this pyramid to the project itself. So the work breakdown structure, I mentioned just how critical that is to the organizational development of the project. But what we're gonna do in this lesson is talk about it in a little more detail and then see what do we do with this information? So how do we proceed from the WBS into an actual activity network is where we start creating the means to succeed? So recall that a WBS is this hierarchical decomposition of the work. Project, deliverables, maybe sub-deliverables and then the activities or the tasks at the bottom of the pyramid. So that's what we want to do with it. The steps that we're gonna use are we're going to define the overall project objective, what it is we're doing. We wanna determine these various work elements as part of this process. And the way I like to explain it to my students is we wanna break the project into manageable pieces, into those manageable pieces. The example I gave of trying to get from New York City, from Battery Park to Brooklyn without any help, any guidance, any means of knowing where to go is a daunting one. So what we do by painting those goalposts along the way, what we do by creating these manageable pieces is we give the project team a visible means to succeed in this activity that they're gonna undertake. The creation of the overall project. Remember, the work package, sometimes I'm gonna refer to it as the task, either one works. The work packages are the lowest element that we're gonna talk about in this hierarchy. And so in doing that, recall that the organization WBS, we have these different levels. The project level, the deliverable, maybe sub-deliverables, and then work packages, and that's the way we're going to go. Remember also that work packages require clearly defined ownership. Who's responsible for this? I want you to think about lesson two, where I talked about the scope management process and one of those activities in there, was to create a responsibility assignment matrix. And it had on the Y axis coming down, it had all the different elements of the work package. Across the top, it had all the key project team members and it was trying to match up the activities with the team members, Who's responsible, who owns each of those activities? Every activity must have a clearly defined ownership, one person responsible. Clearly defined start and end dates. Those end dates imply this is when this will start, this is when it will end, this is what it will create. What I say here is representative of physical accomplishments is another way of saying the start and end of that activity means that at the end point we have completed that activity. Whatever it is that we determine it should be. Third, results that can be compared with our expectations. Remember, we have a plan, this is what we're developing, is a plan. An X set of expectations for what each of these activities is intended to be, what it's intended to create or to do. And we have to have a means by which we can compare the expected with the actual. Don't forget all activities have a budget. There's a budget number associated with that. How does that number come about? Well, it depends. Let's say for example, that we have three people assigned to an activity, and if we know their hourly rate, we can say, all right, that activity, we're gonna show how we do this later. But that activity, let's say is gonna take 10 hours, and I have three people assigned to it at certain hourly rates. I simply take their hourly rates, multiply them by 10 hours. Is there some overhead charge I have to include? That may be the case in your organization, only you know that. Are there other physical characteristics? Do we need physical materials or some other materials that we can assign to that activity? All of those things together come up with our specific budget item for that activity. For most of you, the largest single cost item for assigning cost for activities is gonna be the cost of your resources. The person or people that are responsible for getting it done. How you cost them out is going to vary depending upon the organization you're in. And some of your companies, the accountant or some other financial person will handle this for you because they know all of the overhead charges. So it's usually some percentage of their rate. For example, maybe 40% of their actual hourly rate has to be added on top for overhead. All these combined create the final cost for that resource to accomplish that activity. So the measurable specific budget in terms of dollars, hours to completion, or some other measurable unit, some means by which we can assign a specific target value to that activity. Let's take an example. I'm not gonna spend a whole lot of time with this because we did an example in lesson two, but I just wanna sort of set the stage. Let's imagine a very simple case where a friend of yours is getting married, absolute panic. So this friend assigns you the task of actually organizing a wedding, because you got married yourself a couple years ago, so you have a little bit of a frame of reference. So you start thinking, "I have to plan this wedding. How am I going to do that?" Well, remember, this is our challenge. Here's the goal, here's the piece of paper that's blank, how do I start filling it in? How do I decide what has to be done? So perhaps I talk to friends, the expert opinion. Perhaps I remember my historical example with my own wedding. Perhaps I have other people that I can talk to, to start gathering up the different list of tasks, things I have to do. And suppose I start doing that, and I commit that to paper. So I have a goal, and I start trying to rationalize that goal with activities. So maybe the wedding project is my first number. That's the 1.0 on my hierarchy. Underneath that, maybe decide on a date. Marriage license, you have to get that, bridal arrangements. Okay, underneath bridal arrangements, notice now I have some specific activities. So maybe those first ones 1.1, were deliverables. 1.3 is bridal arrangements, but that's not sufficient, is it? So I have to drill down further and say, "Well, what about the bridal arrangements?" Okay, well select attendants, order the dresses, the dresses have to be fit. You have to do all these sorts of things. But then we get to the ceremony. Rent the church, florist, create print programs, hire a photographer. You can see these are all examples of me breaking down the project into these bite-sized chunks that I've been referring to all along. The deliverables come down ultimately into activities or tasks. And so here we are looking at a variety of the different tasks that are gonna be necessary if I am going to pull off this wedding for my friend. And so I have ultimately taken a project and I've started subdividing it into the various components and I've broken it down further. Remember the term I used earlier? I said it's a deconstruction. A work breakdown structure is a deconstruction of the project down further and further until I get to a point where I can assign specific measurable tasks, that's all I'm attempting to do. So let's assume, this is just an example to show and illustrate the ideas of, again, a work breakdown structure. Goal, practical, what I have to do. Let's take that one step further. So let's assume that we've gotten to the point where we're capable either on our own or through consultation with experts or other members of our project team, or other historical documents. We're at the point where we feel pretty comfortable now about all of these different activities. But the next step is this. What do I do with those activities? How do I now apply them into a project? How do I make them into a project? How do I get something out of them jointly, so that they ultimately equal the project? Well, what we're talking about here is the idea of developing activity networks. Now, activity networks is a fundamental component of a project and of developing the project plan. And so we're gonna spend a fair amount of time explaining how do we develop an activity network, what is some of the key terminology that we have to be familiar with when we talk about activity networks? What do they do for us? What are the rules in developing an activity network? The good news is there's some very clearly-defined rules, so we're not trying to blunder in the dark here. We have some means and some rules by which we can start developing this network. Activity networks, essentially are quite simple, quite straightforward. They're a schematic, so it's a display of all the logical relationships of project activities. Now, there's a lot of elements in that definition, so I want to go through these and pick 'em apart one at a time. First of all, schematic means that it is a display, it's a graphic or it's a figure. It's a display of what the project flow chart is going to look like. The second point, logical relationships is also one we're gonna delve into here in a few minutes, because logical relationships define the nature of an activity network. What I mean by that is would it make sense, going back to my example of the wedding. Would it make sense to rent the hall before the bride has even said yes to the groom? Well, clearly no. Would it make sense to order the band before we've done some of the preliminary things upfront as well? Does it make sense to do these things out of order? Should I order a band and have them on hold for three weeks until such time as I can get this done, while I'm paying their salary the whole time? Well, of course not. I may book them, but I need them down here at the later end of the process. What I'm referring to here is this idea of logic. What order should activities follow in? What should be done first? What should be done after that? Can some things be done at the same time to save us time? All of these questions factor into the decision about how I create logical relationships among all these activities that I've identified through my work breakdown structure. I love this idea, the goal of the activity network is to create a set of visual network paths. Now, there's a lot of words in there that are a little bit fuzzy right now. Don't worry about that because we're gonna come back and we're gonna hit each one of these. But when we say it's to create visual network paths. That idea, again, says that what I want you to be thinking about is what is this schematic? What is this drawing? What is this figure of all these activities laid out in relationship to each other? What is it gonna resemble? That's where the network logic comes into play and that's what we're gonna be talking about now. How do I take a bunch of activities and put them into a logical relationship to each other? Okay, what we're gonna do is we're gonna be creating this set of visual network paths by sequencing all these activities. What has to happen first, second, third, et cetera. That's the sequence we have to pay attention to. Networks take the results of our work breakdown structure and I like the way this is referred to. It says they show their temporal relationships to each other. That's a very fancy way of saying a simple thing. Some of these happen first and some happen later and I have to recognize some things happen before other things have to happen. I use an example in my classes with my undergraduates and I say, "Imagine you're going home for the first time since you went away to college. You've been gone for two and a half months and you're home on fall break, and your mother says, after the hugs and 'you look thinner,' and these other things like that. Your mother says to you, 'You know, by the way, you never cleaned your room, and I asked you to clean your room. I would appreciate if you go in now and clean your room.' So you finally agree just to keep peace in the household. You finally agree that you wanna go in and clean your room. You don't want to, but you're going to. You start looking at all the things. You look at the dishes that are piled up. You look at the crumpled bed sheets that are laying all over the place. You look at all this stuff because mom, true to her word simply closed the door when you walked out, everything was left as it was the day you left for college. So first of all, the smells probably a little bad. Everything is a mess, but just going into cleaning the room suggests you have to do certain things in a certain order." That's that temporal relationship part we're talking about. You can't wash sheets till you strip them off the bed. You can't vacuum the floor till you pick up the old clothes. You can't shine the surfaces of your desk till you remove the old dishes. That's what we're talking about. Anytime we talk about temporal relationships or this idea of network logic, what has to happen before other things can happen? Remember, networks are a work in progress. Now, what I mean by this is a very important point. I'm gonna hammer this later on in this lesson, but let's address it right out of the starting gate. Every time I've been asked to develop a network for any project that I've been involved in, I recognize that it is an iterative process. The first thing I lay out where I say, "Well, this can happen and then this, then this, then this." Someone else will look at it and say, "Well, no because if you do this, then you..." Basically what we need is many eyes looking at that network, many opinions, and we need to recognize that that first thing we lay out is probably wrong or at least is gonna need a lot of modification. That's the idea of a work in progress. So remember that when you develop a network, the first time you do it, put it in pencil because you're gonna be erasing a lot, and you're gonna be changing and altering and modifying as other people offer advice on the order. None of us are experts on this. None of us are gonna get it right the first time. Your network will be a work in progress as you're developing it, so recognize that. Don't feel frustrated if you don't get it right the first, second, or even third time, it's evolving. And that's the idea, it may require many iterations until you get the logic in the correct order, in the correct sequence. Why do we have network diagrams? Network diagrams are a wonderful thing. You can see it right here. I sort of illustrated it all on this one slide to show you not only what's good about them, but just giving you an example of one of these sort of temporally-sequenced kind of things. Notice we have some things happening first and then they lead into other things which lead into other things. Networks allow us to understand the interdependence among all those activities. Some of 'em are critical that they happen early, so that other things can happen afterwards. Networks facilitate communication because they make us aware of not only who is depending upon my work, but who I depend upon. So that person has to finish their activity before I can start mine, and when I'm done, that will lead onto somebody else's. So we're gonna talk to each other to make sure we're on the same page. "When do you expect to finish? When do I get this from you?" That kind of information. I'm gonna show you later that network development also helps us determine project completion. You see, this is the beauty of this. Up until this point, we can have all the best guesses in the world. We can have top management saying, "You have to be done by September 1st." We can say all these different things, but you know what? Until I create a network, a logical network, one that works, until it's all laid out and it fits, I can't tell you how long that project's gonna take. Nobody can. Your boss can order it done until he's blue in the face, but that's not going to change the basic parameters of when that project is going to get done depending upon how it's laid out. So project completion date is not determined by the boss. Project completion date is determined by the project network. Project networks help me schedule resources. I may not need a programmer or a tester until later in the project. Well, when do I need them? Because their boss wants to schedule that person's availability. Just saying, "I'm not sure, I'll let you know," is a bad idea because if you say that, you're setting yourself up for not having that person available when you need them. But the fact is, until you lay out the network, you don't know, you can't. And so it's not until the network is all laid out, and I can look at this network and say, "Aha, this is the point in time at which I'm going to need this individual." Now I can contact that person's boss and say, "I need Carol working on these dates, so I need to book her for this point in time." That helps defray a lot of the ambiguity in when resources will be available because I planned for them. We're gonna see in our next lesson, what I call here critical activities. At this point in time, all I want you to think about is some activities are going to define how long the project takes overall. The way I lay out my network paths, one of those paths is gonna determine how long this project is gonna be. The other ones not so much. They're gonna have a little bit of give, what we call slack time in them. But one of those paths will be very important. In fact, the term we use is critical. So we're gonna use all this network that we create to identify the critical path. The critical path tells us all the activities that absolutely gotta be done when they say they're gonna be done. Networks show start and finish dates, along with the idea of determining project completion. If I set out my network correctly, I'm gonna know when each of those activities is expected to start, when it is expected to complete, and so overall, there's no ambiguity, no possibility of surprise in the system just because I was a little tentative in terms of knowing when these activities were supposed to happen. That will not occur if I lay out a good logical network.