4.4 Create project activity networks - Video Tutorials & Practice Problems

<v ->Let's look what those look like in practice.</v> If we're giving an example here of network logic the way I've been talking about it, let's see what some of these terms look like. Well, you can see this is an activity set of three that are linked in series. I've identified the topic, I've done the research and I've created a paper. Very simple, very straightforward. You notice, of course, they have to be done in that sequential order. I can't skip steps or I can't reorder it because it wouldn't make sense. That's series. Here again, we have a different situation. Now we have activities that are linked in parallel. Following that example I gave, if the paper draft is at a point now where we can not only edit and do the final draft of the paper, but meanwhile, we can prepare a presentation and finish that, then we have these activities that are essentially set up so that they can occur at the same time. There's no reason they can't be done at the same time in relation to each other. Merge activities. Well, here's exactly the example I gave. See how we have three activities, A, B and C, and how all three of these are flowing into D. Remember my point earlier. Activity D, when can it start? Well, it's not a trick question. Activity D cannot start until all three activities A, B and C, have all been completed because Activity D depends upon the completion of all three of those. And here's a burst activity, and again, straightforward. Burst activity, Activity A, has to be done and the minute once it's done, Activities, B, C and D can kick off at that point. So just some terminology that we're gonna see as we move forward. Well, I've given you several rules for how we develop a network and we've also talked about some of the important terminology in developing a network. So let's take that information and let's start refining it a little bit more. Let's talk about a few more elements that we need to know. And I know some of you are thinking okay, when do we actually start? Trust me, we're gonna start quite soon, but if we don't have the rudiments down, if we don't understand the basic components, then it's gonna seem like smoke and mirrors. And as in one of your old math classes in high school or college, if we don't understand the rules initially, it's just gonna seem like voodoo when we get to the point of actually having to solve one of these. So let's make sure we have all the rules in place. The information that I need for network instruction is not that difficult. It's a few things. I need to know the activities. Remember we talked about it. I'm gonna use the work breakdown structure to identify activities. I'm going to do my best to create some precedent's logic as part of that process, because that's all part of the iterative nature of trial and error. So I wanna see, does this have to happen first? Then what can happen, then what can happen? So I have the activities. Then I have descriptions, some description for those activities so I know what they are. I also want to know the predecessors. That's part of my network logic. In order for me to vacuum that rug, what has to be done? Well, remember, I've gotta pick up the clothes. I've gotta know the order things have to occur in. So let's say I have the following information. Let's say I know, very simple example, I know that I have a project now that's gonna consist of just a few steps. I have the first activity, which I'm gonna call A, contract signing and notice there is no predecessor. This is what starts the project. So I know that this has no predecessor to it. B, I'm gonna design the questionnaire. That can't be done until the contract is first signed 'cause I don't wanna waste the time and money doing it until I have a signed contract in my hand. So therefore, the predecessor for questionnaire design has to be signing the contract and it continues. At the same time, somebody in my organization is designing the questionnaire, I have another person who's going through all of my logbooks and going through all of my search engines to identify the target market for this questionnaire, where it's going. Do those two activities have to be done one after another? No, they really don't, because the person can start designing a questionnaire while someone else is coming up with our database of people that we want to target for this questionnaire. So we identify the survey sample. Well, we can't do that until we've gotten the other ones, and you can see then that B and C are predecessors for D. You can see if we follow this through, developing a presentation, while I want to do that and I've determined that predecessor is B, analyze the results, well, I can't analyze the results very well until after I've surveyed the sample. So again, demographic analysis, that's probably relevant to it as well. And so you see what I've done here is I've identified some basic activities. I've described them and I've assigned the predecessors, just that. That's all I'm worried about at this point in time. I bring in members of my project team and we look over this 'cause maybe I scratch this out on a piece of paper just to make sure I had the order right, and maybe when I did it initially myself, I went, I said, you know, C, the target market identification, that has to follow B. And somebody pointed out and says, "Well no, that's not really true. That person can do that while the other person is still working." And I looked at it and scratched my head and said, "You know what, you're right." So we've gotten it to this point and now we have the information necessary to put together our network. Well, a minute ago I explained an example of using a breakdown structure in order to identify the various components, the activities of the project. Very simple example. What I wanna do now is illustrate this and show how we can actually create a network out of that information. Please bear in mind this is intended as a simple example. It's intended really to show the conversion process, how we flow from the one thing to the other, how we flow from a work breakdown structure to a schematic diagram. Clearly, for most of you, the projects you're gonna work on are going to be infinitely more complicated. They're going to have many more steps. They're going to involve a much greater, much more elaborate sort of schematic. In fact, the kind of schematic that you're probably going to need some software package to actually create for you. That's okay. As we're gonna see later in this lesson, one of the elements, one of the means by which we can do this is through these kinds of schematics or through something called Gantt charts, which we'll be talking about that allow us to do this with software packages. My purpose here is simply to help us understand the logic of conversion. So it's a simple example, yes, but hopefully it'll illustrate many of the concepts and many of the terms that we've talked about to this point. So with that being said, let's refer back to that very simple example that we had here of those eight activities. So we started, we said, with contract signing. Now contract signing has no predecessors. Also, therefore it's at the beginning of the project. Also, we called that Activity A. We gave it a label, and so we're gonna start at the beginning. We're gonna start on the left side and work our way over to the right as we said. So recalling that we're using activity on node terminology here, remember that the activity is gonna be embedded in this node or what I'm gonna show you is a box. So let's say we have Activity A here. We know it's at the beginning because we said it's at the beginning. In other words, it has no predecessors. Now coming off of Activity A, we noticed something interesting. We've got two activities now, B, which is questionnaire design, and C, which is target market identification and both of those have Activity A as the predecessor. So we can illustrate that by showing it this way. We can say all right, Activity A has two successor activities, B and C. So I'm going to put B here, I'm gonna put C right here. Now notice one other thing, again, referring to the terminology we've been employing to this point. Do you recognize based on this network logic what Activity A is? This would be considered a burst activity. So we have B and C coming out of our first activity here, okay? So we can go further now. We've started this network project moving into the right direction, hopefully. So let's look at Activity D. Activity D was survey the sample and I had said that that requires both B and C be completed before this can be done. Well, we can illustrate that again here by highlighting the fact that B and C must be completed before D can be done. Lo and behold, we've gone from a burst activity here to a merge activity here. With a merge activity, both of these predecessor activities must be done, completed before D can be started. So the first four activities now are laid out pretty much like this. Let's look further. We know that this developing the presentation, we call Activity E, has one predecessor. In this case, it's B. So for simplicity's sake, and again, in the interest of keeping the the network moving in the right direction, I'm gonna stagger this a little bit. So I'm gonna put E up here and there's B linking that up. So E now has an immediate predecessor. This is a successor activity. F says analyze results. Now F'S activity, the predecessor activity for F is D. Well, if I look down here I can say, okay, there's F. G is the demographic analysis. Now the G, the demographics, requires the completion of C. So the predecessor for Activity G was Activity C right here. So again, let's try and keep the flow going from left to right. So I'm gonna move this over in this direction as well. So we start here with a burst activity. We now have a merge activity. We have another burst activity, B, because two are coming off that. We have another burst activity, C, 'cause two are coming off that. And we're left finally with Activity H, which is the presentation to the client. And notice for Activity H, we had three predecessors, E, F and G. So to illustrate that, to show that it follows on the schematic here, we put H out here at this end, and activities E, F and G all merge into activity H. Now what we've done with this simple example is we've taken our work breakdown structure that we've been talking about, that is so important, and we've said how is this going to look? What is the network logic going to consist of when I convert all of those different activities onto some sort of schematic diagram? But notice, in order to do that, the most critical bit of information that had to be understood as part of this is number one, of course, what are the activities? But number two, what is the predecessor relationship among these activities? Which must come first, which can follow on, which can come later on? Once I know that, once I know the activities and I know their predecessors, the way we laid this out, then it's a simple matter of converting that information into a chart that looks very similar to this, illustrating the start of the project and the conclusion of the project and every step in between and how they relate to each other. Well, what you just saw me do on the whiteboard was walk through this simple example one step at a time, converting those three bits of information, namely, the activity and the precedent and the name of it, and put those into some sort of ordering so that we understood we start at one end. What are the predecessors, what are the successor activities? That allowed us iteratively to build that network that you saw. So what you see on the screen in front of you now is an alternative representation, but it's done exactly the same way. It's simply a case of taking all that information and more importantly, the understanding of how those activities link or are related to each other and now convert it into an actual network. And look what we have here. What we've created is exactly what we were talking about at the beginning of this lesson, a visual schematic that allows me to understand the overall nature of the project, how it flows, what activities depend on other activities, and how this project overall is going to be realized. And that to me is the really fascinating and incredibly important idea behind the idea of network development is it creates a means by which I- So I talked about at the beginning, we take that initial project idea, that creative thought, and we actually combine it into all of the different components. We break down those pieces with the work breakdown structure, but we don't stop there, because simply deconstructing a project into a work breakdown structure, into a whole bunch of deliverables and activities is only partway useful. Yes, it gives me the means to understand what has to be done, but it doesn't tell me how these activities relate to each other. This completed network is now the next step in this journey to understand how we create network logic out of a seemingly disparate group of project activities that all somehow have to be combined in a meaningful way to get us from that starting gate all the way to the finish line. And so this example that we've created illustrates that challenge. Now that's one very important network tool and that is creating the activity network. Another way to conceptualize that same information is through something called a Gantt chart. Gantt charts are extremely popular these days because they combine a certain intuitive logic and indeed obviousness with an overall elegance, showing the layout of a project. And so we can't understand networks simply by looking at that network I showed on the board there a minute ago, because although it's a very useful device and it shows the layout and the network logic of activities into other activities into yet other activities, the Gantt chart is gonna take us one step further down this road. And so let me illustrate what a Gantt chart is and why it's so useful in understanding how to lay out activities. First of all, Gantt charts are all about a time-phased network. Now that's very fancy talk, but basically all that means, folks, is that Gantt charts link all those activities to specific dates. If you remember that example that I just finished, one thing that was missing from that chart was any sort of calendar, wasn't it? Yes, I know what these activities are, I know how they relate to each other. I have a sense of what starts and when it finishes, but I don't know the dates because I can't know the dates based just on what I have in front of me there. Another thing that a Gantt chart does for me is it's very easy to create. It's one of those wonderfully quick to comprehend kinds of charts. So no matter if you're a novice person working on projects, this is your first exposure to them, if you've been around projects for half of your work life, if you are a professor of project management, the beauty of the Gantt chart is they are very easy to create and almost anybody can look at them and very quickly comprehend the critical features and components of them. The advantage again is that we link the baseline schedule, the dates. So this allows me to know when the activities are gonna start, when they're supposed to finish, not in terms of days, but dates. And that's critically important. Let me give you example. If I were to tell you, as we're gonna see in the next lesson, that I have an activity, and let's say that I've determined that that activity's going to take 20 hours to complete, well, some of you might interpret that as saying 20 hours. Okay, let's see, eight hours a day. So basically you're telling me you'll be done in two and a half days. And the short answer is no, that's not what I said. I said that activity will take 20 hours to complete. Now depending upon everything else I have going on, depending upon all my other requirements, I may only be able to do that in four hours that I can devote to it on a daily basis, which means it's gonna take me five days or even longer. There's no way I can know that just by giving you an actual time, unless somehow I link that to some sort of baseline schedule. And that's another beauty of Gantt charts is it allows me to do that. Gantt charts are great for updating, they're great for control. Why are they great for control? Very simply because I know what day of the week it is, I know what day of the month it is, and I could go in at any point in time, pull up my Gantt chart, look at the date and identify the activities that have to be done by this point in time, the ones that should be completing, the ones that should be starting, the ones that are halfway a work in progress, and I can say, "Okay, it's September 24th. Where are we?" And go down the list and identify which ones are on target, which ones maybe are not. That's the idea of updating and control because I know the dates of the week. Gantt charts are great again because they also allow us to identify the resource needs just like with an activity network. The beauty is though that unlike that activity network I just completed, now we have actual dates. So now when I go to the other department head and say, "I need Carol for important test work on this application I'm developing," that person's gonna say, "When do you need Carol?" With a Gantt chart, I can tell him. I can say "The dates that I have blocked off for Carol's work here are" and give them specific dates. That helps me identify the resource needs and when they're gonna become available. What does a Gantt chart look like? Let me give you a simple example. This illustrates a little bit of the idea I'm talking about here. This was constructed with MS Project and it's a very simple example, but I think it illustrates very nicely the point I'm trying to make. Take a look as you go down this list. We start with design of prototype and the duration I've identified is four days. Notice further that the way the Gantt chart is set up is it blocks out Saturday and Sunday and it assumes we're not working on those days in a standard MS Project Gantt chart layout. I can change that, of course. If it's a seven day a week project, we can go in and we can modify that information. But for simplicity's sake, the default is to identify this as taking four days, yes, but in practicality, it's going to take us up into the end of Monday of the following week. Notice further that John Smith is responsible for that activity. Following him, and there's the arrow pointing down, that's one of our precedent's arrows that we were using for activity diagrams. The precedent's arrow says that after design of prototype, engineering comes next. Sue Bailey's responsible for that. After engineering, we have two activities, specification check and parts order, both occurring following the completion of the engineering activities. Again, three days and two days respectively. You can can follow it down, so I won't belabor the point. What I'd like you to pay attention to though is the elegance of a Gantt chart and how easily this lays out not only the activities, but the person responsible for the activities, the amount of time associated with that activity, and most importantly, the overall calendar duration, how long that activity is supposed to take on my project calendar. And those components make Gantt charts one of the most useful tools for establishing a project network. Project networks are our first venture into the discipline of the scheduling process for project plans. This activity and this lesson has codified some of the elements that will make you unique in your organization. Because unlike other people perhaps who have good ideas but don't understand how to operationalize them, you are on the forefront of being able to take that information, those ideas, and understand the steps necessary to make them happen and understand how those steps relate to each other to create an overall network and understand how that network overall creates the project that we're attempting to complete here. So the network that you've created through the work breakdown structure first is a visible, logical schematic demonstration of how we're going to actually create value for our organization. So what do I wanna leave you with in thinking about this? Remember, the idea here is to create the formal logic for project development. You understand that. Nobody can do that better than you and your team if you have the right people on your team because you've broken the project down and you understand those different steps. So you're creating the formal logic for the project development. In order to do that, notice what I say here. It's very important that you make sure that you understand the ordering, that the predecessor activities occur first, followed by successor activities. If you're unsure, try it again. Work this multiple times. You're probably not going to get it right the first few times. And in fact, one of the things I recommend is what I call the post-it note idea of network development. Next time you do a network activity matrix, get a bunch of post-it notes, write out on them the different activities, stick them on a wall visible to everybody, and starting on the left side, working your way to the right, just like we talked about the network logic and start looking at them. Is the sequence correct? Is the ordering right? Can some of these be pulled out? Do they have to follow necessarily behind others or can they be done at the same time? In other words, are some of these activities really burst activities? So more than one thing can happen at the same time once this is completed. Are some merge activities? Play around with this. Make sure that you and your team have looked at it, not just for the logic of it, but also for the efficiency of it. After all, if I have 50 activities and I lay them out one right after the other, one through 50, one following the other, following the other, following the other in the most inelegant sequential diagram, well, strictly speaking, I am gonna complete the project. Is it going to be done in a rapid pace? Probably not. Is it gonna be done as efficiently as possible? Probably not. So part of my job here is to play around with those post-it notes and start pulling these things apart and seeing how many different ways I can create parallel paths so that I can shrink this project down in size. None of us are omniscient when it comes to creating a network. Fresh eyes are always useful. Bring in experts, ask their opinions. They can probably tell you about things you never even considered. They might suggest activities you totally forgot about. They might reorder things because when they did their projects, they found it actually worked better in a different sequence. They might suggest shortcuts or ways that you can be even more efficient. So develop your network, yes. Test your network. Try your network. Pick it apart, criticize it, ask other people to look at it, see what you're missing. The end result is going to be a project that's running as efficiently as possible as quickly as possible, and it's going to give you as much credit as possible.