7.3 Learn the information required to close out projects - Video Tutorials & Practice Problems

<v Instructor>What else do we need</v> to concern ourselves with? Well, again, depending on the project we may have a whole bunch of closeout paperwork to consider the documentation. Make sure that you get all the formal documentation done. Any reports, go back to our lesson on number two on scope statements and talk about the scope management process. We identify upfront the necessary documentation and paperwork that has to be concluded for this project. What legal paperwork has to be taken care of. Is this something you have to concern yourself with? Does your organization have a lawyer who handles all this for you? But there's some issues related to contracts and things like that. You have to close out those cost accounts that I talked about. Make sure that all of your cost accounts, all your personnel. Do you have to do a formal review of every member of the project team? Do you get to do an informal review? It helps some of us think, I don't like doing reviews. Believe me folks, it really helps. It helps your status in running that project team. If team members realize that at the end of this process that person is going to be one of the people evaluating me. Whereas alternatively, if that person meaning you, the project manager, has no real control over my career, no real control over my annual evaluation, I don't have nearly as much leverage with that person when it comes time for asking them to work harder on the project or do something special for me. So what kinds of personnel documentation do you have and what are things you should concern yourself with? Why are closeouts difficult? Now, I'm talking about here good closeouts, the ones where we're actually finishing the project. So we're getting here to the conclusion, why? Why is this a difficult process? There's a lot of reasons and if you think about it in your own situation and in your own past experiences, you know one of the most obvious ones to use a colloquialism is by the end of a project we just run out of gas. We're just tired. We've been immersed in this for days or weeks or months or in some situations even years. And we're just at the end of our tether. We want to be done. We wanna move on. We want new challenges or experiences. Constraints can cause shortcuts on the back end. I don't have all the people available now. Everyone's been reassigned, so I can't get everybody together in a team. So you know what? I'll just write up a very quick lessons learned document and I'll submit that and don't anyone else worry about it. Okay, that's a shortcut on the back end. That actually is not beneficial. Many of the activities by the final point, may be low priority. So maybe there's things that we have to finish here that really don't matter in the greater scheme of the overall project, which is more or less done. But these are events that have to take place or these are activities that I've gotta get done. And so there's not whole large priority with them. So they just kind of get pushed to the wayside. Our lessons learned analysis, if it truly does seem like bookkeeping and like just filling out those administrative details it's not gonna generate any kind of enthusiasm. And consequently, not very much learning as well. There's another mistake that is commonly made and that is what I call the unique view of the project. This is where people sort of look at the closeout and look at the closeout process and shrug their shoulders and say, why do we really need to worry about that? I mean, by definition, aren't all projects unique? So how much actual learning is there from project to project? Well, it's a seductive argument, but it's fundamentally flawed because what this assumes is projects are so utterly unique that no two projects share any of the same problems. That they don't even use the same personnel. That they don't have the same kinds of customers. The same kind of constraints, the same kind of anything. And of course, we know in practical reality that simply isn't the case. Many times we do multiple projects for the same customer. So how do we take in customer satisfaction on an ongoing basis to consider? Many times the same personnel are assigned to multiple projects. So I've got Joe and I've had Joe on four different projects. You get the idea. There's a lot more commonalities in projects going from project to project than we think there is, and it's a seductive argument, but it's also kind of a lazy argument to say, look, all projects are different, so let's not waste a lot of time with this closeout process.