4.2 Learn to break projects down into sub-elements - Video Tutorials & Practice Problems

<v ->Now, I said a few minutes ago</v> that there are some rules in place here. That's good news because just telling somebody, "Go ahead and create a network," you can imagine is a recipe for all kinds of problems occurring. So what we're gonna do is, instead of saying go ahead and create a network, we're gonna say, "But wait, there's some rules here. "There's some elements that you have to pay attention to "as part of creating that overall network "that are going to allow you to do it right," and so I want us to walk through these and I'm gonna try and explain each one of these rules and a little bit of the reasoning behind them. Some of this reasoning may not become clear to us at this point in time until we see one of these actually worked out. And when we see it worked out then we can kind of cycle back and look at the rules again and say, "Aha, okay I see, this is how that rule plays out." So what I'd like you to do is listen to these rules now within the idea or the mind frame that these are important to know but they won't become as clear to us until we actually show them working in practice. The first rule is you have to spend a certain amount of time in what we call precedence ordering. That's not super difficult in some ways. In other words, you don't have to go crazy with it, you don't have to be precise, but you should have a little bit of an idea of what has to occur more or less in what order. Going back to my example of the undergraduate returning home, we said a few minutes ago, "I can't vacuum a carpet until the clothes are picked up. "I can't dust the horizontal surfaces "until the bowls have been taken into the kitchen. "So I can't put on new sheets "'til I've washed the old sheets, "which I can't do till I've stripped the old sheets." So certain things have to be done in a certain order and the more I think about my project and think about the various components of it as part of the work breakdown structure I've done, I should be starting to think that way anyway. It's sort of an intuitive step. When I ask students, "Think about a project. "Give me the activities necessary to complete that project," we naturally start thinking, "Okay, what should happen first?" Right? It's a logical way that we order ourselves. So this isn't gonna be too awkward but we have to recognize that when I do this try and put a little bit of precedence ordering into my listing of all those activities. It'll just help you as you start finalizing and refining the network. Network diagrams usually flow from left to right. So it's gonna start here on a sheet of paper. You'll see that visually it's gonna start here and it's gonna work this way. The first activities to be done are on the left side of the paper and they're gonna flow across in this direction. It's just the way we lay it out. That's one of the conventions. An activity can't begin until all proceeding connected activities have been completed. Let me explain this point. Let's say that I have two activities and for simplicity's sake I'm gonna call them A and B. Both of those activities have to be done before activity C can be started. What that means is that if activity A finishes, but I'm slow in finishing activity B, I'm just slow, activity C can't start. Even though activity A is done, that person got done on time, activity C is still held prisoner to my completion. So you see, an activity can't begin until all preceding connected activities have been completed. If it's a preceding activity but it's not connected, doesn't matter, but if it is connected those other things have to be done first before I can start on the next one. That's part of the rule. We're gonna see arrows. We're gonna see lots of arrows. Arrows indicate logical flow. Some things are predecessor activities, so we call them predecessors. Remember, we start from the left and we work our way right. So a predecessor activity is an earlier one. Successor activities, the arrow goes this way. Predecessor, arrow goes here into a successor activity. So arrows on activities always indicate precedence, what happens first, and then the overall logical flow. We typically, when we design these, we try and avoid as much as possible crossing arrows and I'll show you some examples of that later. We try and keep this as simple and elegant as we possibly can. Sometimes it's not entirely possible but I can tell you the simpler, or at least the more efficient the network is the easier it is for people to read. Particularly not just on our own team but even people coming in, stakeholders like top management, or the client who wants an update on where things stand with the project. If I can show this diagram and show where we are in this diagram it becomes an immediate trigger recognition point. So try and be simple. Try and be elegant when you're setting these up. Now we have a few more rules. Each activity, we have to have a unique identifier. Do you remember my example with the work breakdown structure? I was giving those activities 4.1.3 or 4.1.4. I was giving them all a unique identifier. We do that on purpose. It may be a number, it may be a letter, it may be a code of some sort. It may be a combination of sequence, it doesn't matter. The point is that there has to be a unique identifier. We do this for a variety of reasons. One reason is we use it for cost accounts so that when I'm trying to find out the budget for this project overall or how much has been spent I can go in and I can identify different activities by those identifiers as to ones that are underspent, overspent or on track. So we wanna have unique identifiers for each one of these activities. We don't recycle. In other words, the activity network flows from left to right. It doesn't get out here and then kind of, well we'll spin and recycle this. Some of the old terminology sometimes implied that that was okay, that really hasn't been done for a long time now. So, looping or recycling or coming back or whatever is not permitted in a network. We want it to flow from left resolutely and relentlessly to the right side of the page. I'll explain why that's the case later, but remember a term I used back when we were talking about scope management, I said was to set up a baseline. And the term I used, baseline, what I said was, "Link it to a calendar." I can't link a bunch of recurring cycling back activities to my calendar because they're going back this way. Well, the calendar days flow in this direction so looping makes for a problem. So try and keep things going in this sort of direction. It's not required, necessarily, but it's very common for a project to have a single beginning node, I'll explain what a node is in a minute, a single beginning starting point. It's also often a single point at the end is used. So we have a starting point, even if that's something like begin the project, hold the initial project kickoff meeting, something, and we have a final one at the end. So we try and create a certain amount of simplicity within the complexity of the project network. And again, don't worry about that term node, you're gonna see it here in just a minute. But this idea says we have a starting point and we have a finishing point, usually helps us with the logic for understanding what we're trying to do. So let's talk about, there's two well known examples of network activity terminology or designations. The first one, we call them AOA versus AON. AOA, refers to activity on arrow. So this designation type, the protocol for activity on arrow is that those circles, those nodes you can see there, are only used to link the activities. They have no particular use themselves. They don't signify anything other than the completion of an activity. So if we look at our top network there, we see that activity B, while the node immediately following that doesn't have any intrinsic value, it simply says Activity B has completed and now that that's completed activities C and D can begin. But you see the activity is shown on the arrow itself. Alternatively, the activity on node, AON protocol, is much more commonly used. In this case, the arrow only indicates precedence ordering. It only says this flows into this. It has no meaning itself. So I'm not assigning the arrow to have an activity, the activities are within the nodes themselves. Let me say very clearly, in the old days, maybe when I say old days, 50 years, 40 years ago, activity on arrow was the common terminology. That was the designator that was used most often in scheduling. It is not anymore. Most project management software Microsoft Project, Primavera, Scheduler, most of these software packages, as a matter of course, employee activity on node. They don't use AOA designators, so what I'm gonna be doing from this point forward is using exclusively activity on node. I advise those of you listening to do the same thing. Activity on arrow is really an outdated designation. I just put it up here to show you the distinction between the two. But the nodes, the nodes here are really another word for the activities. The activity is actually on the node itself. What does a node look like? Well, the short answer to that question is it can look like whatever you want it to look like, and I'm not being facetious when I say that. I typically like to put a fair amount of information onto the nodes themselves. I like to use them as an identifier, but more than that, I like to use them as the main basis by which I personally can make sense of my network. And so as a result what you're gonna see is, we have multiple ways that we can identify, or multiple bits of labeling, on that node. Much of this at this point in time, I hasten to mention, is not gonna be apparent to you but it will become more apparent later on. What I want you to see is, to me, this is a fully labeled node. This has all the information necessary really to take a look at a network and make sense out of it, to understand this network in relation to the overall project and its status at any point in time. So you see that we have here some of the most important ones right there in the middle column, the ID number. That's that designator or that identifier that I mentioned a minute ago. Some people will put a very brief activity descriptor there, like develop questionnaire, vacuum rug, doesn't matter. And then the the activity duration down below is what we've determined to be the amount of time that that activity is supposed to take. And again, at this point we don't know because I haven't gone to that degree yet. I haven't started talking about how do we actually develop these duration estimates, that will come later. For now, we're not concerned with it. All we're concerned with is the overall big picture, developing those different activities, that was based on the work breakdown structure, and sequentially ordering them, which is what we're doing in this lesson. And so the rest of this, things like early start, early finish, late start, late finish, activity float, also known as slack, these really are not necessary for me to know at this point in time. I will be revisiting those and then we'll understand exactly how we can make use of that information. As I said, I show this because I'm a fan of fully labeling the nodes in my networks. I think it's useful information and the more we have the better off we are.