2.5 Recognize critical information related to scope reporting, control, and closeout - Video Tutorials & Practice Problems

<v ->I said earlier on that another component</v> of the scope management process is reporting. Reporting asks the question, what kind of information is gonna be collected and reported? Who's gonna get copies of it and how often is that going to occur? So for example, we decide early at the beginning of a project, remember those terms those review gates, we decide, for example, we're going to have four review gates or we're gonna have monthly review gates or we're gonna have review gates after certain points, whatever, some defined idea. And at that point in time, we're gonna collect certain data, our cost data, our scheduled data, quality, any technical issues or what are called exception reports. These are things that didn't go according to plan. So how did we deal with the quality misq? So we're gonna collect certain bits of information at specific points in time. Further, we may say that project manager, the project team, the top manager and the client will receive all copies of all reports. Or we may say, no, just the project manager and the top management will receive certain reports. The client really doesn't need to see other things. So, but we have to decide this, what's going to be reported, who's it gonna be given to and how often is it gonna be done? So typical project reports are gonna contain a lot of these types of information and it ranges in a lot of different issues. Cost status, of course. Where do we stand right now? We had a budget of X amount of money. We've spent this amount of money so far. That's a critical bit of information. Certainly the other one you can imagine is schedule status. Where do we stand relative to that original project schedule we created. Technical performance. How's the project doing? Is it achieving the technical goals it was intended to do? Or are we starting to come up against some technical difficulties? What are some types of control systems? Well, it depends, is the short answer to this question. There are many different ways that we can control a project, many different types of information we can request. The challenge for you is deciding which types of information you really want. Now the reason I say it that way is because there's an important point here. If you deal with some novice project managers or some novice project organizations and you ask them questions like, what kind of information do you want? The knee-jerk response would be to say, Oh, everything. I wanna see it all. I wanna see every bit of status information you have. But is that necessarily wise? For example, does every bit of information we collect really convey to everybody the status or the important information that we need at every point in time? Another way to say that is, I can generate status reports that are this thick and just flipping page after page after page. But is it really going to convey the critical information that I need or that my project team needs in order to assess the status? So we have to be careful in making this decision. What are some of the control systems or some of the types of information that we want to collect on a routine basis? Some examples, change management, we call it configuration or change management. Change management asks what happens when problems occur? What happens when we have to make changes to the initial plan? We were digging a foundation for a new residential development and we hit unanticipated groundwater at three feet below the surface and it's wetlands. And the federal government came in and now all of a sudden they've slapped all kinds of problems on us so we can't continue to dig there. What's our solution? What's the change or what's the alternative that now we have to look into in order to fix this problem? It may be as simple as saying, we can't dig there. We have to shift the site of the foundation to another dryer location where we're not likely to hit groundwater. That would be an example of a change management decision. We started here, we came into difficulties so we had to move to another locale. Those are the kinds of things we're talking about. It may be more technical, of course. We may want information on the design. The design is working as it was originally laid out. The design for this new computer system doesn't work. The Hubble we thought would work fine until we got it into outer space and discovered that we had done poor milling of the actual lens. And so the design is off once it was mounted and put into orbit. Now we have to come up with solutions. Other control systems, maybe trend monitoring. Trend monitoring says, okay it's not enough to tell me the status of where we are. Are we $3,000 above budget this reporting period? Is that an ongoing trend or is that a one time situation? If we don't have some sort of trend monitoring to follow the dots as the project moves through, we don't know. So maybe another bit of of information I want to collect is trend monitoring information to allow me to assess how the project is moving forward. Documentation. I wanna make sure that I have all the documents necessary. So another type of control system here is the documenting or documentation of all the materials that I need as I'm moving this project through. Is there acquisition? There's acquisition control systems related to the idea. I have to acquire other people, I have to acquire other material or other resources from other sites. So there may be information there. I have to control the acquisition of those other sources of resource for the project. Specification control. This is very simply the kinds of specifications for the project that we need to verify that it is doing what it's intended to do within strict parameters. So for example, if I'm developing a new electronic system that has a certain speed for the electronics to refresh themselves and I'm developing it, the specification is clear. So I have a bound or a parameter set upper and lower control limits of where that refresh signal should come in. If it's not achieving that, that's an issue that I have to be able to attend to. I may not know that unless part of my control process includes something on specification control. I said at the beginning of this lesson that one of the ironic components of scope management is that at the very time we're planning for the project we're also planning for the project's completion. It's closeout. So while I'm thinking about how this project is going to operate, I should also be paying some consideration to how will this project conclude? When will it conclude? In under what circumstances will it conclude? Remember, we don't have to be precise here. We don't have to come up with a very logical conclusion, everything laid out because let's be honest, we're just getting started. Are we likely to run into problems along the way? Absolutely. Will the final project be what we originally intended it to be right at the beginning? Maybe not. Maybe dramatic changes will have to have occurred from the start to the completion. So closeout information here can't be too precise because we just genuinely don't know that much yet in terms of the details of how that project's gonna conclude. But we can make some educated guesses, or at least we can make start thinking in terms of what will be necessary for an effective closeout. And these are some ideas or some things we should consider. For example, we always say, the job's not over until the paperwork's done. All the necessary sign-offs, everything that has to be detailed, all the final materials, all the final warranties, all the final sign-offs on the different departmental accounts or any temporary accounts that were created for the project or the project team, that all has to be concluded. So the closeout documentation we use this number one, to resolve disputes. If you and I start arguing once we've completed the project as to who is responsible for this or you know, when you started this project you promised me it would do this. I developed the project and I said, no, no, no. I said the project project would do this. Well that's why we need closeout documentation to resolve precisely these kinds of disputes. So when we argued there was a dispute, this is how we resolved it. We have documented proof now of how that resolution occurred. We want closeout documentation as a training tool. What did we do right? What did we do wrong? Next year when we bring in new project managers, what can they learn from this process? What can they take away from this in terms of lessons to be things to do and things not to do? So we use closeout documentation to make sure that project managers, future project managers understand what we went through so they won't make the same sorts of mistake. We use closeout documentation to facilitate auditing. Auditing is what the accountant or in some organizations the project manager has to do at the end of the process. Usually it's a third party because we need somebody who can look at the process with a fresh set of eyes who's not intimately involved in it, and they wanna audit what worked, what didn't work, where's the money, what's left over in the accounts or how much did we overspend our budget, God forbid, these sorts of things. So the auditing of all of the paper trails can only be done well if our documentation is up to speed. And as part of the closeout that's part of the auditing process for that as well. So some of the things in closeout documentation that we wanna make sure that we have are historical records. Be comprehensive, keep track of all memos, all communications, all technical meetings, all minutes of meetings, all kinds of documentation for that project, every meeting with the client, every meeting with top management, every meeting where any information was collected, hang onto it because the closeout documentation is the perfect place to park this, to make sure that all historical records are in one location. If possible, make sure to get e-copies. Electronic documents are a lot more useful cause they're a lot easier to send out. Just hard copies end up getting put into binders and collecting dust someplace. So make sure that you have all the historical records. Make sure that you've done a post-project analysis. We'll talk about this more so don't worry about it for the time being. But when we get to the termination discussion in the final lesson, we're gonna talk about how do we conduct a really useful post-project analysis to find out what worked and what didn't work, and more importantly, why do we think. We have to close the project out financially. We have to make sure that we start wiping all of the records of all of the different accounts, the charge accounts and the different accounts for this or for that. So that has to be done. We have to make sure that the accountant is heavily involved in this so we understand precisely what the final cost of the project turned out to be. That's part of historical closeout. If you think about scope management as a process and what we've talked about here in this lesson, one thing that should come to mind is the idea that it is a very comprehensive process. I mean, think about it for just a second. What I've walked us through here is what we used to refer to as soup to nuts, meaning start to finish of a very involved, very comprehensive and fairly complicated set of steps. The other interesting thing about scope management is as I said, this all happens early in the process. This is when we're still at the earliest stages in the project life cycle, conceptualization and planning. We're just setting the stages here for the project to succeed. We're also covering a lot of ground. We're going for everything from the very beginning, the start of the project, all the way to planning for how we're gonna control it and finish it off, the closeout at the very opposite end of the start. That's a lot of work to do and I know some of us think it's almost too much work. It seems like that's an awful lot to do before we even get started with the project. But here's what I'd like you to reflect on. After 25 years of teaching and researching and consulting in project management myself, after a lot of experience, one thing I can tell you and I can tell you with absolute clarity, most projects that succeed set themselves up to succeed right at the beginning. Most projects that fail have set themselves up to fail right at the beginning. Why? Because they didn't take the time to comprehensively cover these steps. They didn't understand what was involved in a project scope. They didn't take the time for conceptual development, for work authorization, for developing all these critical documents and all these critical steps that are gonna save them so much grief later on. There was an old commercial for Fram oil filters and some of you may remember it, most of you won't but it was a very interesting commercial. And it went like this. There was a very gruff voiced mechanic with grease up to his elbows, standing, holding a Fram oil filter. And behind him was a car on a lift and he was in an auto body shop. And he said basically, you see this, this is an oil filter. If they had put a new oil filter in that car, it would've saved them $1,500 for the engine rebuild that I'm doing on it now. This costs about $10. 1500 versus 10. And the slogan that Fram used was Fram oil filters: you can pay me now or pay me later. What I'd like you to think about is this whole idea of scope management is exactly in the same idea. If you do scope management, you can pay me now a little bit. If you ignore scope management or worse if you do just sort of a half-hearted job with it, you will pay a lot more downstream. Scope management sets the stage for success. Once we're there, we can start moving forward much more confidently.