2.3 Learn the critical elements of the scope statement - Video Tutorials & Practice Problems

<v ->So the scope statement process, how does this work?</v> What is gonna be involved in this scope statement development? Remember, our goal here is to establish, number one, the project goal criteria themselves, these things that we've talked about. Well, how much is the project going to cost? How long is it expected to take? What kinds of quality or performance goals should come out on the back end? In other words, what will the project do and do well? What kinds of deliverables can the customer expect? What will we present to them once the project is completed? Those are the goal criteria. Those are the ways that allow us to know did we in fact achieve project success. If I don't have a serious set of goals, how can I possibly measure my performance against them? I simply don't know if I have achieved success or not because I never established upfront clearly what the goals were intended to be. We need to develop review gates along the way. Now, briefly, I'll talk about review gates later on when we discuss one of the later lessons, but briefly, review gates ask this question, and it's a fundamental question: While we're developing the project how will we know how we're doing? Are there periods or points in the project that are particularly good for us to stop and maybe review what has happened to this point, compare our current progress against anticipated progress, make sure that the relevant clients or the relevant stakeholders for the project have signed off on it? This is an example of a review gate. And review gates are, think of a toll booth on a highway. Toll booths force us to stop, force us to pay something or collect something, then allow us to continue on. Review gate forces us to stop at a certain point in time and do an evaluation. Okay, to this point in time, here's how we've done. Here's what's working. Perhaps here's what's not working. What are our remedial steps we should be taking? These sorts of ideas. That's the nature of a review gate. Companies need to be willing to build in review gates into their projects. We need to have capabilities to take looks at the projects along the way, not to simply allow them to run, and run, and run, and run, and at the end of a year, a year and a half or whatever the original assignment was to ask the question, Well, how's it going? That's not a good time to be asking how the project is proceeding. The more often and the earlier we ask those exact questions the better we are capable of maintaining control of the project. So do we have these sorts of review gates as part of our goal criteria established initially? We want to develop a management plan for the project. And I'll talk a little bit more about this in a few minutes, but the management plan is essentially saying: How are we gonna run this? Who's gonna be involved in the project? Do we have a hierarchy? Do we have a reporting structure? Who is the project manager expected to report to? Does he have one report? Does he have multiple reports? So we want to create this management plan early for how the project's going to proceed. We wanna establish a very, very important idea, something called a work breakdown structure. Now, work breakdown structure, again, I'm gonna talk about a little more detail later, but I want to give us an idea right now for what a work breakdown structure is. Imagine, if you would, that you've been assigned to a project. Now think about your undergraduate days or think about your current work situation. It doesn't matter. The first time that you're assigned a project, you're given a challenge, you're given responsibility for something, if you're like the majority of us, myself included, there's bound to be some initial panic involved. That's understandable because all I have is a concept. All I have is a goal or maybe a series of goals but no means to achieve them. You've just given me the pot of gold at the end of the rainbow, but you haven't told me how to get there. That's my challenge. The work breakdown structure is this idea for how I'm going to actually address that challenge. And I'm gonna get to this idea here in just a second because it's so important to running a project successfully. But lastly, notice creating a scope baseline. All a scope baseline means is tie in the project to a calendar. What is our date? When does this project start? When is it expected to end? Saying nine months duration is not nearly as useful as saying September 24th, or whatever the duration might be. We need to recognize that having a scope baseline with actual fixed dates in it is a huge advantage to understanding all those different goal criteria, and more importantly, when we need to assess them. So let's take a look. I said a minute ago that the work breakdown structure is absolutely critical to the project. Think of it this way. Imagine for a moment you have never been to new New York City in your life. Suppose that you are a stranger. You've grown up on small towns and you've never been to New York City ever. So one day you magically get deposited downtown at the very tip of Battery Park on the southern tip of Manhattan Island. And you are told that you need to be at a certain address in Brooklyn and you have four hours to get there. You can't take a taxi, you can't ask anyone for directions. You're on your own. Get from, no Google Maps, no nothing like that, get from Battery Park to Brooklyn in four hours. That's your goal and that's your timeframe. The constraints are no help, no other support, find a way to make that happen. That's a pretty significant challenge. But suppose, suppose I threw in one additional feature. Suppose I said, the good news is that at every corner, at every street corner between here and your goal I'm going to paint one of the street's lamps gold. So all you have to do is go to the corner, look around when you spot that street lamp that's painted gold, head in that direction. The minute you get to that street lamp, start looking again. Do you see another gold one? And low and behold up over there is another gold one. So you follow and you find that one. And you get to that one and you do the same thing. Well, all of a sudden if I add in that little feature, this trip from Battery Park to Brooklyn isn't nearly as daunting, is it? Because I've given you milestones, I've given you steps along the way. I've made it clear that in order to get from here to here, you have to go here, here, here, here, here, here, and then finally here. That's kind of an odd example, but in another way, it really encapsulates this notion of the work breakdown structure. Because on one level, all you know is that you have a project and you have a bunch of criteria. You know how much it's expected to cost, how much time you have to do it, the other constraints, these sorts of things. So you know what you have to do. You have the constraints in hand. But how do you do it? Well, the work breakdown structure says this is what we're going to do. We're going to set a project scope by breaking down that overall mission, get from Battery Park to Brooklyn, that overall mission into a cohesive set of increasingly specific tasks. So that big overall challenge is gonna be broken down into a bunch of little bite-size challenges, little steps along the way that allow us jointly when all these are done collectively and put together will create that project. Now, when you put it in those terms in a classroom setting or in a work setting, you see this sense of relief that starts to flow over people because now it's not the mysterious challenge anymore. Now we've broken it down into a series of discrete activities that are gonna allow us collectively, once we complete all of these activities and combine them, that's going to equate to that overall project. And when you put it in those terms that doesn't sound so bad. Well, that's what a work breakdown structure conceptually does. Now what does it look like? Let's talk a little bit about what the work breakdown structure is supposed to do. First it's supposed to do is it supposed to echo the project objectives. So for example, if I started painting street lamps going in the other direction toward the the Palisades and the the Hudson River instead of going east toward Brooklyn, we have a problem because I've set up a bunch of steps but they're going in the opposite direction. That's not helpful. So the work breakdown structure has to echo these project objectives. It has to create a logical structure so that you or I can look at that and see that makes sense. I see how all these discrete steps equal that big project. It has to give us the ability to communicate project status. And by that I mean if I know that my project consists of five steps and I've completed three of them to this point in time, that gives me a good sense of the overall status of the project because three down, two to go. So that's part of the idea as well. It communicates project status. It helps improve communication. Again, if I know that I'm responsible for this activity, and that activity, and that activity, Joe is responsible for those two activities, Carol's responsible for these three activities, and all of them jointly have to be done to complete the project, I have a lot of incentive to talk to Joe and Carol to make sure that we're all on the same page and that the status of our individual activities is proceeding well. It creates a project control structure. What I mean again by that is as the project manager you need a means to assess how the project is going at any point in time. Remember, if all I have is an idea or a goal, no matter how specific my project goal is, if I have a goal and I have a bunch of constraints but no other idea of what has to be done to achieve that goal, how can I possibly control it? But once I've broken it down, then I can control it. So let's see what that might look like. This is a very simplified example of a work breakdown structure and some codes that are attached to it. You see what I've done here is I've just given a piece or a component of the overall project. And up there at the top in purple at the 1.0, this is the overall project. So this might be getting to Brooklyn, if you will. All right, let's change our example because we've already worked that one to death, but this is the example of the project overall. Underneath that, I have a second layer. Now the second layer are called deliverables. Deliverables generally are groupings of multiple activities or tasks that have to be done in order to achieve that deliverable. So for example, if I'm developing a new software system, the software is at the very top. That's the project. Underneath that I have coding. So I have all the activities related to coding. That's one deliverable set. I have testing. That's all of the activities related to system testing. I might have documentation. That's another deliverable. And I have all the activities related to the documentation that has to be done once those other things are done as well. So you see that overall software project is getting progressively broken down. And it continues. Maybe we have sub deliverables. Not every project uses sub deliverables. Many projects just stick with a project then deliverable and then finally, the work package level. Work packages, another way to think of work packages is work packages are individual tasks. So the individual activities that go into making the project succeed that we're gonna talk about in a minute, those are at the work package level. Those are the most specific activities. And you see how accomplishing those allows us to accomplish the deliverables, which ultimately allows us to accomplish the overall project. Everything is broken down as specifically as we can make it because then collectively we can bring it back together and combine it into that project that we're seeking to complete. This is a very simple example that I put together off of Microsoft Project. All I did here was I took a simple case of a project. In this case, I call it an IT installation project. And I'm just showing you some of the elements involved in it. Matching the information technology to organizational tasks, okay that might be a deliverable within this overall project. Underneath that are some activities. So in order to match it, I have to conduct a problem analysis. I have to identify the information on the technology. Identify IT user needs. So I have to go through a set of activities related to that deliverable and so on and so forth. And you can see what MS Projects, or in in fact any other scheduling software, allows us to do is do this same sort of hierarchical development of the project. So I start at the top and I start breaking it down not just into deliverables. Because if you see, for example, 1.1 matching the information technology to organization tasks, that's not very precise. That doesn't really tell me what it is that I need to actually do. So I need more information. In other words, okay, how do I do that? How do I match our information technology to organizational tasks? Well then you can see 1.1.1, okay, first, Jeff, I want you to conduct a problem analysis. You get the idea. But you see what I'm doing here is I'm trying to break this down into specific elements that allow me to complete the overall process. And this is the kinds of things that you'd be doing when you're putting together your work breakdown structure. Work packages. I said a minute ago that work packages are the most specific examples of the work breakdown structure. They're at the lowest level in the work breakdown structure. They are intended to identify the specific tasks. So one of the things that they do is they are a deliverable result. Conduct a problem analysis. Develop a questionnaire for our customers. Complete the coding of this particular subroutine. These are deliverable results. They are supposed to have one owner. They're not collective. They're not something that 12 of us are working on. They should have an identifiable person. Joe or Carol or Sue is expected to complete that particular activity. Think of them as miniature projects. Think of that activity as exactly that. It's a little microcosm of the overall projects. I might have dozens and dozens of these individual activities that overall are going to allow me jointly to create my overall project up here. But think of each one of these as its own individual miniature project. It's something that has to be done by a person within a certain amount of time and completing or delivering a specific deliverable result. They should have milestones attached to them. Work packages, we should know how long they're going to take. That's part of our scheduling challenge, which we'll address in a later lesson. They should fit the overall organization. Now, I don't mean the organization, the company. I mean the overall organization of the project. There should be a purpose for them. They should be there and fitting in with that big work breakdown structure we created. There should be a place in there where I can point to a specific, say, Aha, that's Jeff working on this activity, which will contribute to this deliverable, which will be part of this overall project. That fits the overall organization. So think of those work packages, those tasks, as little microcosms of the overall project, but understand just how critical each individual task is to the overall project. We can't skip a few and do a few others. When I was 18 years old, I tried rebuilding an automobile engine with my brother-in-law. When we got done, we had a few pieces left over. That's not good news. When you finish rebuilding an engine you should basically have the things in the engine that you took outta the engine initially. So everything should fit back in again. We can't run a project where at the end, well, we did most of it, but there were five or six of these activities here we didn't do very well. That's probably going to impact overall on the project. Each component has to fit. Lastly, work packages should be trackable. What I mean by that is they should, because they're miniature projects, they should have a defined duration. How long is your work package supposed to take? How much is it gonna cost us? Who's working on it? How does it fit in with other things? In other words, can we track it? Can we assess the status of your activity? If we can do that, if we can do all of these things that you see on the screen, then we have a work package that is gonna be useful and contribute to how that project goes. Here's another suggestion. As part of your scope statement, who is involved in the project? Use that information that we've developed, that work breakdown structure, and now let's put some faces to those different activities. Let's not just think of these as activities themselves, but let's think of them as activities in relation to the people working on the project. Not only that, let's think of them in relation to the people working on the project and how they have to coordinate with each other. Now, that's a critical point. It's not enough to say, Carol's doing that activity, I'm doing this activity, and Sue is doing that activity. That's okay, but what does that say about how I depend upon Carol's activity before I can do anything with mine or what Sue depends upon me in order to get her work done? You see, if I don't understand not simply who's responsible for the activities but our relationship to each other, then we have a problem in terms of coordination among those different tasks. And as a project manager, one of the things you're gonna be required to do is keep track not simply of each activity, but you also simultaneously have to hold in your head the overall project. You have to see how each of these activities relates to the other activities. So you see, one of your challenges as a project manager is being both a detailed person but also being able to fly at what we call the 10,000-foot view. So you keep in your head or on paper, but you keep a track of the overall status of the project. Now, if your project is composed of several hundred individual tasks, you can quickly see how complicated this can become. So I've got a lot of different things I have to pay attention to. One way that that I can start doing that with this responsibility assignment matrix is you can see on the Y axis here I've identified just very simple examples of a work breakdown structure. So I've got some of those different activities, the deliverables, and then the task, and I put a little code next to them. On the X axis across the top there I have the lead project personnel, the people who are responsible. And notice how we can set this up. We can say along the bottom there that you'll notice that for problem analysis, that's task 1.1.1. If you slide all the way across there, you'll see that Bob, who is from the IS department, Bob is responsible for completing that. But Bob is also responsible for keeping Dave in the loop. Dave is also from information systems. He's the one there with that black square box that's underneath his name, and he's being kept in notification. Meanwhile, if while Bob is working on his activity, if he runs into trouble, notice who he can call upon for support. Well, Jim, over in R&amp;D is specifically designated as his support for getting that activity done. And you can see once Bob is done, because he's kept Dave in the loop, Dave is under there under notification, Dave is set to get started with his component of the project the minute Bob finishes. So Bob's done, he notifies Dave. Dave has been kept up to speed, so this isn't the first he's heard about it. And now Bob's done, Bang, I can get started. Now notice what happens. Dave is now taking over activity 1.1.2, developing the information. Sue is kept notified, Bob is the support person to help out, and so on and so on. And you can see the only reason for this is that it requires not just the project manager but the critical project team personnel to recognize how they link up. And it's a great communication tool and it's a great coordination tool for making everybody aware not just of their responsibilities, but their responsibilities in the greater scheme of things, how my responsibilities line up with everybody else and how we all have to work together in order to make this happen. So one of the components of the scope development is creating, after we've done the work breakdown structure, we know who our personnel are, we now know what our activities are, and now we can combine the two and create this responsibility assignment matrix that allows us to link those two things together. It's a marvelous tool for coordinating the activities. When you do one of these, make it public. Put it on the bulletin board. Pin it to people's office doors if necessary. Make sure everybody is aware of this so there's no ambiguity about people's individual responsibilities for their assignments.