PMI PMP Project Management Professional – Implementing Project Integration Management Part 3

13. Manage Project Knowledge

Let’s talk about managing project knowledge. This is a new process in the PMBOK Guide 6th edition. So I would expect you’ll see plenty of exam questions on this. On your PMI exam let’s check out the edo’s and talk about manage project knowledge. Our inputs will be the project management plan. Our project documents things like the lessons learned, your different team assignments, a resource breakdown structure, source selection criteria, talking about choosing vendors and the stakeholder register you’ll have deliverables so past work creates things.

These deliverables will be an input and then enterprise environmental factors and OPA tools and techniques. You need expert judgment. You need a knowledge management so some type of a way of doing knowledge management, having information management and then some interpersonal and team skills, which include things like active listening, really hearing paraphrasing what’s been said to confirm that you understand it, looking for feedback. You need facilitation. So some meeting management here to facilitate conversations.

You have to do some leadership, do networking with your peers and colleagues and stakeholders and having some political awareness, understanding where the power is in an organization. My outputs of managing project knowledge will be the lessons learned register the PM plan updates and OPA updates. Managing project knowledge as I mentioned, is a new process in the Pinbach Guide. So I’ll anticipate you’re going to see a few questions about this on your exam. It’s a way of managing existing knowledge. What do we already have in our organization, what knowledge exists here and how do we access it and utilize it and allow it to contribute to our project. It’s also what new knowledge so training and hands on experience and job shadowing.

So we do cross training in the team, so what new knowledge are we trying to generate? And we want to document that knowledge to openly share it. So we’re talking about our current project and future projects and even part of operations. So that’s all about managing project knowledge. There are two types of knowledge you want to be familiar with. We have explicit knowledge and tacit knowledge. Explicit knowledge is very quick and easy to explain. Explicit knowledge is there are eight pallets down in the warehouse I need you to pick up and bring to the job site. Or in order to use this piece of equipment you hit this button here and then you have to hit this button here and then that allows equipment or here’s how you turn it on or whatever the case may be. It’s just real quick. We have 130 activities, there are ten project team members. It’s just very easy to explain how to do something. So that is explicit knowledge. Tacit knowledge is more difficult to express.

Tacit knowledge is the knowledge that comes by years of experience, just a deeper understanding by doing this activity for years that individuals has a really talent for making that happen. A great example of that, I was helping a painter on a project I was on and so I’m no painter. I think I can throw some paint on the walls. So he’s having me tape up like the windows, and they’ve got that blue tape and I’m sticking it on the windows and he’s doing the same thing. And I’m doing what I’m doing. And I look over and this guy is just he just knows how long it is and sticks it up.

And his are all clean and eating. Mine is kind of raggy and rolling down. It just looks like an amateur put that tape up. I was like, well how do you do that? And he’s like years of experience and he just was so fast because he’s been doing it forever and he just knows how to do it. So it was kind of hard for him to explain to me how he does that. He just had the experience. So it’s the know how when doing a task that’s tacit knowledge explicit is you take the paint, you put it in the bucket, you dip your paintbrush in it and put it on the wall. It’s just step by step. But tacit is that real, genuine know how. I mean obviously there’s more to painting than that. Little description. There some knowledge management techniques, there’s ten of them that you want to be familiar with. Storytelling. Storytelling is I’m going to tell a story and that helps you have a deeper understanding of the experience. Knowledge fairs and cafes. This is kind of a neat little trend where you have these little booths or tents and people move from tent to tent to get a quick lesson. So it’s a knowledge fair cafe.

Work shadowing, I mentioned earlier, work shadowing is where you follow an expert. So you shadow them and so you go and you watch them how they put the tape on the windows and by watching you get a better idea or a deeper understanding. So it’s work shadowing. Reverse shadowing would be where the painter was watching me put the tape on the window and then giving some coaching and they would say, joe, you got to do it like this and this far and get a clean break or whatever. So reverse shadowing is the expert follows the amateur doing some creativity and ideas, management techniques. So brainstorming, affinity diagrams, mind mapping. So we’ll see some of those a few times. But just a way of how can you use creativity to identify information or to create knowledge or to have some AHA moments when it comes to different parts of your project. Discussion forums and focus groups. So online we use a forum or a focus group.

Everybody comes together to remember it’s facilitated. Do some networking, talk to other colleagues about their experience again online, like on LinkedIn or Facebook, some communities of interest or your local PMI chapter. So some special interest groups and you might have some special interest groups with the technology or the discipline that you’re in. It’s not just project management, of course. And then you have meetings. You want meetings where you’re going to talk about the project and the approach, and having a uniform approach in that project and training events are a great way to share knowledge, so everyone gets the same message on how to do that task. So those are ten knowledge management techniques. Remember, explicit knowledge and tacit. Those are two key terms for you, I’m sure, on your exam. All right, great job. Keep moving forward. I’ll see you in the next.

14. Monitoring and Controlling the Project Work

Project Integration Management is pretty big, isn’t it? So we’ve talked about initiating, planning, executing. Now we’re moving into monitoring and controlling. And this is our next process to monitor and control the project work. Monitoring and controlling is an Iterative activity that we’re doing this throughout the project. It’s going to happen all, all the way throughout is all about the project manager having control over the project team. And a lot of times we will see it kind of disguise as you’re monitoring something, you’re managing something. But what we’re really doing is ensuring that what’s happening in execution is what should be happening in execution based on the project plan. So planning and execution obviously go together. But we also have kind of this umbrella here of monitoring and controlling that execution had better match what was planned, and if not, we need to respond to it. Let’s look at the edo for monitoring and controlling the project. A lot of inputs. Here your PM plan, project documents. Look at all these different documents. The assumption log. How did you create your estimates, your time and cost estimates? What about cost forecasting, the issue log, lessons learned, register that milestone list. We saw that back in Planning and Initiating with our charter are quality reports, the risk register, the risk report schedule forecast, work performance information. Remember, data information. We have agreements like contracts and then EEF and OPA. Our tools and techniques, expert judgment, new term, data analysis. So in data analysis, we’re going to look at these different analysis types. You have alternatives analysis, cost benefits, earned value analysis, root cause, trend analysis, variance analysis. Then we have decision making and meetings.

Our outputs of monitoring and controlling the work, work performance reports, change request, our PM plan updates, project document updates so you could be updating, things like your cost forecast, your issue log, your lessons learned, your risk register, and even your schedule forecast. Let me take just a minute to address something here. A question I usually get about this time in the course is all of these different documents you’re not explaining like, I don’t understand what a quality report is, I don’t understand what a schedule forecast is. It’s okay. Project integration manager. Remember? Is chapter four in the PMBOK? It’s our first chapter. It’s also the largest of all of the chapters. The reason why the processes in Project Integration Management will touch initiating, planning, executing, monitoring, controlling, and closing.

We have a process in every process group. This is the only knowledge area that does that. That goes all the way through the whole project management lifecycle. So right now, to talk about quality reports, for example, we don’t talk about that in detail in chapter four, that’s done in detail. Chapter four of The Pinbox, that’s done in detail in chapter eight in the Pinbox on quality Management. So right now, when you see these different terms or documents that you don’t quite understand or you haven’t quite been exposed to yet. Just know, okay, those are coming. That right now we’re seeing an input. So based on what happens with that quality report from chapter eight, that would affect, how do we monitor and control the quality? Because remember, this is like a big umbrella. So that quality report could help us do some data analysis.

Well, where are our quality problems or that schedule forecast? We could say, all right, we’re slipping on our schedule. How does that affect earn value as far as our schedule performance index or whatever you want there? So I know we haven’t looked at all these terms. We’re still kind of upstream from all of these because we’re just in chapter four in the PMBOK.

So don’t get discouraged. Just know this stuff is coming right now. Just roll with it. This is integrated management, project integration management. So what we’re looking at here is how it’s integrated with all of the other knowledge areas. So right now you just got to kind of roll with it. If you see something you don’t know, just say, okay, I know that’s coming. Take a note of it. And then when we get there later, you’ll have that AHA moment. Let’s talk about the difference between monitoring and controlling. Monitoring is more like an oversight. Controlling is more like ensuring and enforcing. So monitoring you do with activities like collecting and measuring, looking at the measurements

before and after, is the process improving, how healthy is the project? What areas are going to require tension? So monitoring is more observation driven. Controlling is what corrective and preventive actions do we need? Let’s do some replanting here. I’m going to follow up on these action plans and then have these plans, have they improved our performance? So you can see monitoring is more observation and controlling is more enforcing and being involved. So we need both. But there will be times we see that we’re only monitoring or only controlling. Some activities that you do in monitoring and controlling, you look at actuals against planned, you assess performance to see, do I need corrective or preventive action? What about the status of my risk?

So we’ll do some risk tracking and then we need some accurate, timely information about the product. So we have to maintain that this thing that we’re creating, it has to be updated and we want to communicate that and track it. We’ll also give information on status reports. We’ll talk about measurements and forecasting, like cost and time scope, when we’re actually going to be done monitoring, implementation of approved change requests. So a change is approved. Got to make sure it goes into the project. We’re going to communicate our status. So status reporting. And if we want to make sure that our project is aligned with our business needs, that it’s not drifting away. Got to keep things in alignment with what our business value and our business needs were for the project. Let’s talk about some terms you’re going to see throughout monitoring and controlling. In each one of our knowledge areas, we have alternative analysis. Alternative analysis are just what are my alternatives? So I can use Oracle or I can use SQL.

I can use Oak. Or I could use Plywood. So those are alternatives. When it comes to monitoring and controlling, though, alternatives are, okay, well, what type of corrective and preventive actions do I need to fix and prevent problems? So what are the different solutions I could come up with? So alternatives to just redoing the work? Is there a fix here? Instead of having to go out and redo all the work, can I make some adjustments? And it’s okay? Cost benefit analysis. So corrective actions in relation to the cost benefit of actually doing those corrections. So you think about this room as eggshell white and it was supposed to be bone white. It’s just a little tiny difference there. All right, it’s going to cost us one $200 to redo it, or can we just live with it? We made a mistake, but now we’re just going to live with it. So, cost benefit analysis, earned value analysis, and we’ll talk about this in chapter seven in the Pinbox. But earned value is a suite of formulas to show project performance. So it’s a whole bunch of formulas that are going to say how healthy is the project?

And we’ll see that in chapter seven on cost management, but you can really use that throughout the project. Some other things here about data analysis and monitoring, root cause and causal analysis. Root cause is where we aren’t looking to treat the symptoms, we’re looking to treat the cause. So the classic example here is you have a runny nose. Blowing your nose or wiping your nose, that’s the symptom. But understanding you’ve got an allergy, that’s the root cause. So in a project, it’s, well, what’s actually causing activities to be late?

Or what’s causing this defect from this piece of equipment? So I’m looking for causal factors which are contributing to the effect. So this is where we get into cause and effect analysis. And we’ll see that in quality, in detail. Trend analysis. Am I noticing a trend? Am I always having to deal with one person that’s late? Are we consistently having a problem from a piece of equipment? How it’s stepping when it’s creating, it’s punching out a material or it’s creating a product and it’s consistently off just a little bit? So is there a trend there? And then variance analysis, we do a lot, a lot of variance analysis. Variance analysis is simply the difference between what was planned and what was experienced. So you have cost variance, schedule variance, you could have some quality variances. So variance analysis is what’s the difference here? And then that helps us find root cause. All right, good job. Keep moving.

15. Performing Integrated Change Control

Performing integrated change control is probably the most important process in this chapter. I’ll say it’s really up there. Maybe the charter is the most important, but this is the one you’re going to be working with probably the most as a project manager perform. Integrated change control is all about when a change is introduced. It’s how is that change managed and then how is it approved. So integrated change control, we’re going to look at the whole flow of changes to approval being deferred or declined. Need to know this for your exam. Let’s look at the inputs. First off, the eto. So inputs we have the PM plan. You’re going to look at your cost management plan, configuration management plan, the scope baseline schedule and cost baselines, the different project documents you’ll need your basis of estimates, so cost, time requirements, traceability matrix, the risk report, work performance reports, and then of course the change request.

And EEF because there might be some rules or policies and OPA because you might have historical information tools and techniques that do integrated change control. Expert judgment, that’s the primary tool and technique here. You’re going to use some change control tools, data analysis, alternative analysis and cost benefits analysis. And then decision making. You can do voting, there’s an autocratic decision making, multicriteria analysis and meetings. The outputs. You have the approved change request, you have PM plan updates, project document updates and the change log. Integrated change control happens throughout the project. You’re going to do integrated change control throughout the project. As soon as the project is created and the charter signed off on, integrated change control can come into play. It’s the responsibility of the project manager. So you own integrated change control anytime.

We have a baseline, so our scope, our schedule, our cost, our project management plan, anytime you have a baseline, if you want to change it, you have to do integrated change control. Integrated change control examines the effect of the change on the entire project. You can have verbal change request but they should be documented. So if the CEO comes to you and they say I want to change XYZ in your project, you don’t say, sorry, it’s not documented, you can’t do it. You would take that change request, write it down, confirm it’s correct, and then it would enter the change control system. So a verbal change request could happen, but it’s really not recommended. Integrated change request is all about capturing the change and then seeing what effect does this have on the project as a whole. So when a change is captured, when it’s documented, it enters the change control processes. The change management system, which is technically integrated change control, that’s technically what it’s called. The configuration management system is also involved because if there are changes to the features and functions like the blueprints or the house, we’re going to move that wall 2ft. That’s obviously a feature and function that’s being changed.

So configuration management is involved, changes are approved. They can be deferred till later, or they could simply be rejected. The change approval level is defined in the project plan. What this means is part of your plan, particularly in scope management and cost and schedule, you could have a threshold for any change above that threshold is automatically rejected. So for example, any change that would cost more than $10,000 that is rejected, any change that would take longer than two weeks, that’s rejected. Any change that would require a new permit is rejected. So those are all change approval levels. In addition, you could say that those types of changes, the project manager can’t make that decision that has to go to the sponsor or a change control board. A change control board would look at certain types of changes or in some projects that could be all changes and they would make the determination, is this change allowed or should this change be rejected? So the change control board, it’s typically a group of executives or key stakeholders and they do the change approval deferment or rejection. And then, as I mentioned, you have this concept of over under approval rejections. Let’s look at change request as outputs so processes can create change requests.

So a process could tell you this is a change that needs to happen based on poor quality, based on we’re late or we’re overrunning on time, corrective and preventive actions to defect repair could be change requests. Typically they are. And then any update to a formally controlled document baselines that those are always going to need a change request. But in your organization you could say the stakeholder register is set. So if there are any new stakeholders, we’re going to change that, that has to go through change control. Or you could say that the contract is set or the agreement you have with another department in your company is set. So any changes to those types of documents could require a change request. Configuration control, like the blueprints we talked about earlier are any changes to the features and functions must go through configuration control. This defines how the project works completed. So it has to be exact, it has to be an agreement because it’s all about the deliverables that are being changed. Generally, whenever you change the scope of a project, you need configuration control. The configuration management system, three terms you need to know. With configuration control we have identification, status, accounting and verification and auditing. Identification is just the documentation of all of the components of the deliverable of the product. Status accounting is the documentation about the product information.

So give me the metrics and the specs on these different deliverables and that’s what we’re going to measure against, that it’s of quality that it’s accepted and it’s really what the customer will inspect against. And then we have verification and auditing. Are the features and functions I should say, are they performing as planned? And what about the functional attributes? Are the functional attributes of quality? Are they acceptable? Will the customer sign off on it? Because we have met the requirements. So that’s configuration control, identification status and accounting verification and an audit and auditing managing project change, right? So still an integrated change control. We’re talking about changes to the documents we’ve already talked about, but there’s some other things here we need to address unapproved changes.

So an unapproved change can be things like you have a developer and they’re going to add a field or they’re going to add a button or a little tool they think is really nifty for the piece of software, but it wasn’t in the original plan, it wasn’t in the requirements. So that’s an unapproved change. It happened, but we didn’t approve it.

So we need to deal with that unapproved change. Now, unapproved changes, we’re also talking about changes that change request that goes through the process and then it’s rejected. Just because it’s rejected doesn’t mean we throw it away. We put it in the change log, we document it. We also communicate why it was rejected and our condolences for that rejection. Maybe not, but you document it. You tell people why. You just don’t keep people wondering, well, why didn’t my change request get approved and why was it declined? And we documented in the change log because when we get to Scope Validation, the customer does an inspection at Scope Validation and they say, hey, where’s that button?

Where’s that field they asked for? You’ve got it in the change log that it was already declined and it’s been communicated that it was rejected. Scope creep is really important. Scope creep are these tiny little changes that bypass the change control system. So scope creep is where you have a developer adding those little features just because they think they’re cool, or you have a stakeholder going to that developer and saying, hey, I know you’re working on this, but could you add a print button? And could you do a saved PDF feature? And can you make this go to my phone and say, yeah, sure, I can make that happen.

And they work their magic, that’s scope Creep, where it’s bypassing our defined change control and it’s considered project poison because this is our scope, right? Let’s say this is our scope. Well, when that developer is creating things that are not in scope, all this business over here, it’s bypassed change. We’re not paying for that time. We’re paying for time for things that are in scope. So things that are out of scope, you’re robbing time and money from what was approved. So you’re creating things that aren’t part of the project, but you’re billing it to the project.

That is scope creep. Project poison. Gold plating is really bad. Gold Plating is where you get to the end of the project and let’s say you have $125,000 left in the project. Well, a couple of things here you might be thinking is, I’ve got all this extra money. Let’s go add these cool features that really the stakeholders are going to love. Okay, that might be good in theory, but the stakeholder might be able to use that money which isn’t yours, use that money somewhere else in the organization. They might have a project over here that’s bleeding cash and they need that money to save this other project. Or they want exactly what was requested. They don’t want all this other stuff. They want exactly what was requested. So they might be really eager for the thing that you’re creating and then you’re taking time and money on things that were not in scope.

So that’s considered goal plating. It’s like you’re dipping things in gold just to spend the money doesn’t necessarily make it better. Track changes is a way that when a change is requested and approved, it has to get into the project plan. It has to be executed, it has to be verified. A good example of track changes here is defect repair. Remember defect repair? Those tiles weren’t installed properly, so we have to do it over. So we paid to do the work wrong. We paid for that waste of materials. Now we have defect repair. We got to pay for it again and we’ve got the time again. So defect repair validation is where I have to go out and confirm that it’s of quality and that it is in scope. Let’s look at the entire integrated change control workflow.

So a lot of stuff happening here, but this is the big picture. Know this for your exam. A change request comes in. That’s the first column here in blue. A change request comes in. Changes generally come from scope, cost, schedule procurement, but you might have corrective action, preventive actions, policies, procedures or resources that need to be changed. But it’s from the most likely to the least likely. Okay, well, when a change comes in, if it’s a scope change or changing features or functions, it will go into configuration management and into change management. If it doesn’t touch features or functions, it’s just going to go into change management. Recall configuration management is all about documenting and controlling changes to features and functions of the product. So generally, scope are going into configuration management. Everything, including scope, that’s a change request will go through the change management system.

The change management system then will determine how that change is managed. So the change management system will say, does this need to go onto the change control board? If one exists, is this beyond our threshold? So the change is rejected. So what do we do with this change? Most likely the change is going to go right into integrated change control. Integrated change control will examine each change and they will say, what effect does this change have in the remainder of the project? So the customer wants to move that wall in the kitchen over 2ft. We’ve already framed it out. So let’s look at the changes that could happen here. What would it do to our scope? Definitely a scope change. It’s going to take more time, it’s going to take more money. Could be a quality issue because now the living room is different. It doesn’t match up with the other walls in the living room. Resources are needed. I have to talk to the architect and the engineer and the draftsman. I might need some more permits. So resources, communications, I have to talk to all those people.

Oh, back to resources. Don’t forget you have to buy the material to frame the wall in the new spot. Could introduce some risk. There’s some electrical issues that happen there. There might be a risk of a delay because we have to get approval on these permits to move the wall. Procurement could happen. You have to buy new stuff, you have to hire the electrician again, you have to pay for the architects time. So procurement could be an issue. And obviously stakeholders, there’s a lot of stakeholders involved. There all those different resources, human resources, the customer, the project team, the inspector. So a lot of stakeholders are involved. So integrated change control happens from integrated change control or through the change control board. We’re going to have one of these four items over here on the right, these one on the green. So what’s going to come out of it will be the change will be approved, decline or deferred. Deferred, meaning? Well, not now, maybe later. Sometimes that’s a nice way of saying no. The PM plan could be updated if it’s approved. You’ve got a change to your scope. There’s lots of things that are going to be updated in your project management plan. You may have to update project documents like your scope and requirements. Documents could be the risk register, stakeholder register, your schedule, your cost.

So lots of project documents could be updated regardless of if it’s a change is approved, deferred or rejected, it will be updated in the change log because you want a history of the outcome. Be very familiar with this for your exam. I guarantee you you’re going to see questions about integrated change control. Sometimes an integrated change control, the change control board or the project team or a group of stakeholders and SME’s need to get together and vote on should we do this change. So when it comes to voting, you can be unanimous, you can have the majority, or you could go with the plurality. Recall the plurality as we’re talking about. The biggest block is who gets the decision. So you could have a change request and you could have no, yes deferred. And if there’s more people, let’s say with no, ten people say no and 15 people say yes, and then you have maybe 30 people that are voting, they say, let’s just wait till later.

They defer it the decision will be to defer it, even though there’s yes and no over here. That’s like they don’t count. Autocratic is one person decides. So yes or no? We’re not doing it. We will be doing it. Multi criteria decision analysis. We’re going to see this a lot. This is just a real fun way of saying you consider every factor for making a decision.

So multi criteria, there’s a lots of different criteria. Time, cost, scope, what resources. Those are different criterias that you would look at. So should we do this or not? So it’s a decision matrix. A lot of times it’s predefined where you could say we have to look at how big of a scope, how much will it cost, how much time does it introduce risk and what’s quality. Just for example, it doesn’t have to be that every time. My point being, you have lots of factors to consider, so you kind of package them up and you say, these are the most important that we’ll weigh this change request against to make a decision if we should approve this change or not. All right. A lot of information here on integrated change control. Really know this material for your exam. Very important. Probably our most important process in this chapter.

16. Closing the Project or Phase

We’re still working away here in project integration management. The good news, this is the last process we have to talk about in this knowledge area. This is also the largest knowledge area. So I know you invested a lot of time in this chapter. Let’s talk about closing the project or phase. To close the project or phase we’re talking about, the whole project is done. Remember, at the end of each phase we could do closing, but we could also be closing out a contract. So that’s a closing activity. Let’s look at our edo’s here to close the project or phase. So to close out the project or phase are inputs we need the charter, the project management plan, and a whole bunch of project documents. The assumption log, your basis of estimates, change log, issue, log lessons learned, register your milestone, list your communications, the QC measurements, the different quality reports, requirements, documentation, the risk report, the risk register. So a lot of businesses going into closing out the project or phase because I need that stuff to create the final report and to confirm that everything’s been done according to plan and everything’s closed out. I’ll have accepted deliverables and business documents, the business case and the benefits management plan, tools and techniques, we’ve seen all of these already. Expert judgment, different types of data analysis. The new one we have here is regression analysis. We’ll talk about that coming up and then meetings, outputs of close the project or phase.

You have lessons learned. Register the actual product, the final product service or result transition, the actual final report, and then OPA updates. Because what you create now becomes part of OPA administrative closure. This is a term that describes the confirmation that all of your documents and deliverables are current. So that’s the first part of administrative closure. This is the actual process, I should say, of how you close out the project. Now, administrative closure is not a process, one of our 49 processes, but it’s really the execution of closing the project or phase. It’s how you officially close down the busy work of closing down a project, making sure that all your issues are resolved. And then all of your deliverables, they’ve signed off on, they’re formally accepted. And then all of the costs, you want to gather all the costs, make sure all the costs are charged. The project, you can close out the project financially.

Administrative closure is all about closing all your project accounts. So all those different accounts, different vendors that everyone’s paid or invoices or purchase orders, all of that has to be done. Financial closure, your personnel and the team, they’re no longer needed because we’re closing down the project. So they’re reassigned to other projects or they go back to operations or whatever the case may be. You might have excess project material, so you’re in construction and you’ve had some backup material, or you have some spare parts or whatever the case may be. What do you do with that? How do you get that into inventory? Or can you send it back to the vendor for a refund? Or can another project utilize it? So what do you do with that excess material? You got to put it somewhere you can’t just ignore it and then reallocating any facilities or equipment.

So a way in your organization is saying, all right, we’re no longer using this piece of equipment. It’s open if somebody wants to use it. And then creating your final project report where you define was the project successful or not? Throughout the project, you can do closing when it comes to contract closure. So you close out your contractual agreements. It’s just a formal way of saying both parties kept up their end of the bargain here. If you do have any claims, you have to finalize open claims. So a claim is a disagreement about who’s in the wrong. Here where you tell the vendor you don’t think this is of quality, and the vendor is saying, hey, it’s exactly what you asked for, so pay us. And you’re like, I’m not paying you. Oh, yes they are. So you have this back and forth and it’s no fun for anyone. So you have to finalize those claims as part of contractual closure. If everything goes smoothly, which most of the time I think it does, there might be some small claims here and there are issues here and there to resolve, but you update your records to reflect the results and then you archive that contract administration for future usage.

So that helps you in the future say, oh, I want to work with this vendor before, or you want to stay away from that vendor. And here’s why. So you archive that information. It’s called the procurement file, and we’ll see that in chapter twelve in the Pinbox a long way from now, right? We’re here in chapter four. Some things that you do in closing. You have to create a final report. You could do this for the whole project or each phase. You may have to audit the project or the phase, was it successful or was it a failure and upfront. Remember, in our benefits management plan, in our charter and our scope, we set the criteria for success. So that’s what we’re measuring against.

Manage knowledgement continues on. How do you share that or transfer that knowledge? So this thing you’ve created, it’s going to go into operational transfer. They need some training or instruction or communication about it. We’re going to complete lessons learned, and then archive that project information. Some other closing activities, you got to transfer the product, service or results into the next phase, into productions or into operations. So whatever you create, somebody’s got to take it, known it, and be responsible for it. Now, we’ll also finalize any suggestions for improvement.

So anything in the project we could have done better, and anything in the organization that would have worked better. So some of these policies, you might realize, are kind of outdated or not very useful. So can you make some recommendations here? Sending those suggestions on to the appropriate organizational unit. So HR, your PMO, whatever department you’re working with, and you want to measure stakeholder satisfaction, make certain that people are happy with what you’ve created. So how do you measure that and quantify happiness? So you need some surveys and interviews and things of that nature. In some instances, people are not happy and the project has been terminated. So early Project Closure project was not doing well on time or cost, so it was canceled. So when you have a project that’s terminated, you just don’t walk away from it. We still have to do some closing here.

So why was it terminated? Maybe it wasn’t a bad thing. Maybe there was a new technology or you made a realization that this wasn’t feasible. So you’re going to save time and money. So it’s not always a bad thing when a project gets canceled. Often it is, though. You have to talk to the stakeholders and go ahead and complete as many project closure activities as you can do, like ensuring that all of the payments have been made, ensuring that the access materials have been accounted for and are released. Any resources that you reserved are released. So you’ve got to make sure that everything’s closed down so other people can use those resources and materials and so on. You do create a project final report, even if the project is terminated early. And when the project is successful, you have this final project report, and it’s basically a summation of what happened in the whole project or in that phase. It defines what was met.

And then what about quality and any variances? So what happened there and was it of quality and acceptable? Were there some variances? What about cost and time? So are there any variances with cost or schedule? Any variances here? What about the validation? So the customer signs off on it that you have the final product and they accept it and it’s good. So you need to sign off. You may have to talk about did the project meet or fail meeting the business objective, that’s no good. If you don’t have business value or costs are out of control or the schedule is way too long, that affects business value. And then what about the risk in the project? Were those handled appropriately and how were they closed out? And what can you learn from that? All right, a lot of information here, but it comes to closing, remember, you can close the project and you can close the phase. Great job.

17. PMP Coach: Interruptions

You’re making great progress. Covered a lot of grounds already that we’re all the way into module four in the Pinbach guide. I know this chapter, Project Integration Management, can be a really tough chapter. Often when I teach this in a live class, I can see the Bible body language of people in this chapter that they get a little exhausted. They might seem a little bit overwhelmed because there’s so much material. Project Integration Management is kind of tough because not only does it have a process in every one of our process groups initiating the closing, it also affects all of our other knowledge areas. It affects scope, time, cost, quality, resource management, communications, risk, procurement, stakeholders. So it really affects the rest of the project.

It has these huge waves, not just ripples, but waves into the rest of the project. So here in chapter four in the Pinbox, this large chapter affects everything else that we talk about. So when I teach this live and I look around the room and I can see the body language of folks, and people start to look a little exhausted or worried that, oh, I’m never going to get this, or they get a little defeated, don’t let that be you. This is kind of a big parent chapter.

So if you feel a little beat up right now because that’s such a big section, a lot of material, just know this was the largest one. There’s no more as big as this. From here on out, we’re talking about very specific knowledge areas. Like, we’re just going to talk about cost, we’ll just talk about quality, we’ll just talk about scope, where this chapter really spans everything. So it kind of beats this up, especially when you’re studying to pass an exam. So take heart. Maybe now is a great time to take a little break and then come back in here right away. And let’s go into our next section, section where we’re going to talk about project scope management. But be confident. Know that you can do this. We’re getting better. You’re making progress. You can do this. I’ll see you in the next lecture.

18. Section Wrap: Implementing Project Integration Management Project integration

Good job finishing this section on project integration management. A lot of material to know, but a very important topic for your exam. This is chapter four in the PMBOK guide. 6th edition. Project Integration Management. We talked about how this knowledge area, project Integration Management, is the only knowledge area to have a process in all five of our process groups. So that’s why it’s so big, because we’re addressing each one of those processes as we move through the material. In this section, we looked at creating the charter, really important process here. Talked about benefit measurements, method so future value and present value and some of that business you’ll need to know for your exam. We looked at creating an assumptions log, creating the whole project management plan, the deliverables that we create, work performance data.

We talked about the issue log, managing project knowledge, a new knowledge area and the different types of knowledge. You want to recognize those characteristics. We looked at monitoring and controlling the project work, mapping out integrated change control, configuration management. Really important topic there about features and functions. And then we talked about closing the project or phase. All right, good job. A lot of information. You did it. You knocked out the first knowledge area. As we continue to move through these knowledge areas and the remaining chapters in the Pinbox, now we’re getting into the very essential information that you must know in order to pass the PMP. And I have confidence that you can do it. All right, keep pressing forward. I’ll see you in the next lecture.