Master Project Integration Management for the CAPM Exam

5. Execute the Project Plans

We've created a project plan. Now we're ready to execute our plan. And that's what we're going to talk about in this lecture about getting things done. Plan as much as you want, but it has no value until you execute the plan, until you go about working to get things done. So that's so important. And that's what we're going to talk about in this lecture about getting things done. And one of the first processes that will do analysis is to direct and manage the project work. Most of the time, you are not the individual doing the work, your project team is. So they're doing the work to satisfy the project objectives. They're executing the project plan. This is where you spend the bulk of your time and the bulk of your money to get the project done. Not in planning, in execution. This is also where you manage, train, and lead the team. So you're developing the team. That's execution. Here's where you'll complete procurement. Not in planning. That gets a lot of people.

The actual procurement activities are part of the execution, which is about directing and managing the work. You'll manage sellers here, and so this is where you'll acquire, manage, and use resources. Resources aren't just people. So we have materials, tools, facilities and equipment to get the work completed. So this is all part of the execution. Also in execution, we're going to manage risk. We're going to get approved for changes to the project. We'll manage communication with our stakeholders, not just to, but with our stakeholders. And this is an area where we're going to collect data. Remember, we have data, information, reports. So we're going to get data on allfacets of our project, particularly on time, cost,scope, quality, and then just overall progress. And then we'll analyse it and report it. So, work performance reports. Here's where we do our lessons learned documentation. And then, throughout the project, we manage stakeholder engagement. A really important process So let's look at our eto here for directing and managing the project work, our inputs. We have a project management plan that makes sense. We have any approved change requests? This is really important.

When we have a change request that's been approved,we have to flesh that out into the project plan. We have to incorporate it, communicate it,plan for it, and make certain that our team executes on that change. Because what we don't want to happen is for a change to be approved. But then our team doesn't know and they do work that is in contradiction to our change. So now we have to undo work to incorporate the change. So that's why it's important here in directing and managing the project work is that you're communicating the change and ensuring that it does happen in the project. And of course, we have EEF and OPA now, tools and techniques, expert judgment. We've seen that a few times. Here's a new term: your project management information system. Sometimes, just PMIs. This is things like Microsoft Project or BaseCamp or Primavera, whatever software you want to use to help manage your project. That is a project management information system. So the PMIs are pretty generic. They're not going to say Project or BaseCamp or Primavera or what have you. It'll just be PMIs. The Project Management Information System And then another tool or technique here to direct and manage your work is your favorite. And that's meetings. So we'll see meetings a lot and meeting management a lot. Look at all the outputs we got for directing and managing the project work. We get deliverables. You're creating stuff. A deliverable is the result of project work. You get work performance data. It's number data, raw data.

You get change requests. You could do the work and then you have to do a change request if the customer wants something different. So a change request could come about. Project management, plan updates, and project document updates. Those are all outputs of directing and managing the project work. There are some actions that you need to know about for your project, and we'll see these throughout the course. The first one is a corrective action. That's where your project is not in alignment with your plan or your performance is not doing so great. So you make a corrective action to realign project performance. A preventive action is where you take some steps to ensure that future activities work well, that your project improves and doesn't repeat mistakes. It's typically preventive action. Defect repair is when you have an error or a defect. So it's non-conformance, it's not-conforming to the project plan. So you have to edit that. You have to go out and redo the work to get it back in alignment with project requirements. Typically, these actions are going to have a change because it's time and money that you're spending to fix some type of a mistake. So let's look a little bit more closely here at some corrective actions.

Corrective actions: you're fixing the project, so something's not working and how you're executing the project. For example, you have a project meeting on Friday at 430. You are awful. Nobody wants to go to a meeting on Friday at 430. So you either fix the project or your reports don't provide enough information, so you fix the project. A corrective action could also be that the team was to paint the room yellow and they ended up painting it blue. Well, that's a defect. So we have to take corrective action. We're doing a defect repair by painting this room blue instead of yellow. And then defect repair validation means that we come out and inspect the repair. We make sure that no yellow is bleeding through the blue, that it's done with quality, that it wasn't rushed or done sloppy. That's all for defect repair validation. So these all fall under corrective actions. Preventive actions are things like safety and making sure you have the right goggles. If you're in a manufacturing environment or any type of safety equipment and construction or whatever discipline you're in, I'm sure there are safety measures that you have to take or your discipline takes. What about training? People need to know how they do their job, so we do competency. So some training, or can you anticipate some problems just based on the nature of the work and your experience in that industry? So you anticipate problems and you plan to prevent that problem.Preventative actions can also be tied to risk management. We have one risk response. We can do anavoidance, so we just avoid the risk altogether. All right, good job finishing this lecture. just giving us a good overview of planning. And now we are into executing, which means next up is monitoring and controlling. And I'll see you at the next lecture.

6. Monitor and Control the Project

All right, welcome back to our discussion here in project integration management. We're now going to talk about monitoring and controlling the project, something that you'll do throughout the project logic, not just intermittently. This spans most of the process groups. I say most because it really doesn't go into initiating, but definitely planning, executing, and then, of course, monitoring and controlling. So let's talk about monitoring, controlling, and what happens in tandem with project execution. So monitor and control the project. This is from the Pinbachuide fifth edition. four of the characteristics of monitoring and controlling the project. We're comparing our actual experiences with the project management plan. Remember that when we were planning, we were creating an agenda and communicating our intention for what we were going to do in the project. So we compare what we planned to happen against what actually happened, and the difference between the two is a variance. We'll also be assessing project performance. How well is our project performing? Now, this is measured against our key performance indicators, typically our three baselines: time, cost, and scope. But you could also assess project performance based on team performance or people completing their tasks on time and as planned. What about our risk responses? How are they going? What about our communications management plan? So it's more than just time, cost, and scope. Those are the three most common things that we'll be looking at as project managers.

We are consistently looking to identify new risk events. Risk identification is an iterative activity that's going to happen throughout the whole project. It makes sense, right? We don't just identify risk once and then never look at it again. It's something that we'll do on a regular basis, always be on the lookout for risk. And that's not just for you, the project manager. This is something that our project team will need to do as well to identify risks throughout the project, not just once and done or taking an occasional glance. We always want to see if there are opportunities or if there are threats lurking in our project. And then we'll need to maintain information about the project's current state. So where are we right now? So what have we accomplished and what's left to do? And you can do this through something like a burn upchart or a burn down chart where you look at the number of activities or number of deliverables you've created in relation to how many you have left to do. So we're always looking at the project's current state. And so this is setting us up for a little bit of something we'll see in chapter seven in the Pinbuck on cost, and that's earned value management. So we'll look at that coming up a little bit later in the course to give you something to look forward to. Let's look at the edo for this activity of monitoring and controlling the project work. You can see we have a lot of inputshere in order to monitor and control the work because we're considering a lot of things that we're measuring against what's actually happened in the project. So, of course, our project management plan is needed because that's what we said was going to happen in the project. So what's our intention? What's the forecast?

Are we reaching the point of our milestones against what we promised our milestones? So is there a schedule variance? Of course, cost forecast. So what did we say it was going to cost? We are measuring it against what the project is costing us. Validated changes are an input because we want to see those changes being incorporated and delivered upon in the project. Changes have thus been validated. And then we have work performance information. Now recall that we have work performance data, raw data. So we analyse it, and now we have data. We have usable information. And then, of course, enterprise environmental factors and OPA. All right, tools and techniques. There's your favourite expert judgment. We see that over and over where I'm leveraging other people's competencies and their brain power to help me make the best decision in the project analytical techniques. So I'm going to study what's happened in the project against what we said was going to happen and what has actually happened. So I need to do some analysis. And then PMIs. You're going to use Microsoft Projector Base Camp or whatever your favourite piece of software is, and you'll need meetings for monitoring and controlling the project work. I may have change requests. I may have to take preventive or corrective actions.

Maybe there are new things that are added to the scope or even taken out of the scope as a result of monitoring and controlling the project work. And then it could also be more than just scope. I'm going to be clear on that. It could be you need more time or you need more money. So those could cause the change request as well. Based on how the project is performing,we take our work performance information and data, and now we have work performance reports that we're communicating that data. Then we may have to update our project management plan and we may have to update those project documents. So those are our outputs for monitoring and controlling the project work. One of our inputs was enterprise environmental factors. So let's take a look at enterprise environmental factors that we would use in order to monitor and control the work. Well. government and industry standards. As a result, any government regulations, standards, guidelines, or standards that are specific to your application area or industry and that you must follow may have a work authorization system. This is really important. When Jane finishes her activities, how does Bob know it's time for him to start his activities? So we need a company work authorization system. If your company doesn't have one, you might create an internal work authorization system for your project. But an enterprise environmental factor is a way of how you authorise work to begin, and so that helps record time and where people are spending their time. So accountability is critical, especially in a matrix environment where people come from all over, have day-to-day responsibilities, and are working on other projects.

So a work authorization system is really important. Another enterprise environmental factor is risk tolerance. Your organisation may have some rules on how you analyse risk and how you score or rank risk,and then how you respond to risk that may have a high probability or a high impact. Now, for now, let's just understand that risk tolerance is an organization's willingness to take on risk later in the course. In chapter eleven of the Pinbach, we'll talk about risk tolerance in a little bit more detail. So this is one of these instances where we have to hint at something that's in the future in order to move forward down.And then, of course, your company may have a PMI that's preferred. You have to use Microsoft Project or Primavera or whatever the case may be. Another input that we saw for monitoring and controlling the work was organisational process assets. Now remember OPA, that it can come from past projects or historical information or it can be prepared for you, like from a PMO or templates, things of that nature. So OPA here are the communication requirements that you have to adhere to or the preferences of your organization. So what types of forms or templates or how do you communicate project information? What are your financial control procedures? So if your project does have a costvariance, what is the process to respond and control that cost variance issue and defect management because we're monitoring and controlling the work? If you find a defect, we find an issue. How do you log it?

In an issue log, how do you track it? How do you communicate that? So your application area may have different approaches. So, like in health care, you are probably going to have a different approach to defect management than you might have in a small entrepreneurial firm. It's not saying that one is better than the other; it's just that the application area that you're working in may influence how you manage issues in defects. Change control procedures are part of OPA. So how do you identify a change? How do you do integrated change, which we'll talk about coming up, and then how do you incorporate that change? So what are your change control procedures? Risk control. We saw risk identification just a moment ago and risk tolerance. So what is the risk control? How do you monitor risk in your projects? How do you track those? How do you document the outcome of a risk response or a risk event? And we'll talk more about that in Chapter Eleven of the Pinbock Process Measurement Database. How do you know if your processes are working? How long does it take to complete a process? I'm not talking just about the PM processes, which are at 07:00 P.m., but also the internal processes where you work. How do you procure it? How do you get people on your team or off your team? How do you escalate? While those overlap with our 40 07:00 P.m. processes, there are also unique characteristics of how you do those processes in a given environment. So what's your process measurement database tracking of how long it takes to complete a process and how effective your processes are. And then lessons. Learn database. And this is a sneaky little nugget that dropped in here as an OPA lessons Learned Database.Yes, we're talking about things that happened before this project, but for you, the project manager, and your team, lessons learned, they're not done just at the end of the project.

A lot of times we do a project post mortem with a lesson learned at the end of the project. And that's fine, and that's good,and that's part of closing. But we need to be doing lessons learned throughout the project, not just at the end. So we contribute to this lessons learned database as our projects are in motion. Let's talk about some forecasting. That was one of the things that we saw in the schedule forecast and cost forecast. And again, this is setting us up a little bit for earned value management in chapter seven of the Pinbuck. So we do some scheduling forecast estimates to complete. How much more will you need to complete this project? Schedule variance. What is your schedule variance? The difference between what was planned and what was experienced So that's a schedule variance. The schedule performance index This is a number that gets closer to one, the better you are. But it's looking at what was planned in relation to what actually was. Where should you be and where are you? And that gives us a number that shows ascore like zero 95 to 99 or zero 67. So a zero of 67 would be really bad. Zero point 99 would be pretty good.

One would be perfect. Cost Forecast: We have the same idea, an estimate to complete. How much more do you need? Now compare that to the scheduled forecast. expected completion date How much longer will it take? I may have said cost earlier up there of aschedule, but it's how much longer will you take? What is your estimated final cost of the project likely to be based on current performance? As a result, estimate at completion. Cost variance What's the difference between what was planned and what actually happened in the project? And then our CPI. Our cost performance index. This is a number much like the SPI that shows how well you're performing on cost. So 0 90 is that you're losing about $0.10 on the dollar. At Zero Point 99, you're performing pretty well. So the closer to one, the better you are. You might be tempted to say, "Oh, I want to be greater than one." I want to be like, "1.9 would be great." 1.9%? Really? If you get too far above one, that probably means your estimates were bloated, and that it looks like you're performing really well, but in reality, you probably have more money and more time than what you really needed for the project. So it looks like you're either ahead of schedule or you're doing great on time. Probably. The estimate said it would take this long to do in reality. It's taking this long to do, so that's not necessarily a good thing. All right, we'll talk more about Earthvalue management and these factors when we get to module seven. But this is part of monitoring and controlling. All right, good job. Let's keep moving forward, and I'll see you at the next lecture.

7. Perform Integrated Change Control

Perform integrated change control is one of the most important processes in this module, really one of the most important processes in a project. Really pay close attention to how you perform integrated change control. That change can affect the entire project. So this is something that you really need to know for your exam, but that you also really need to know is your role as a project manager. So let's take a look here at this process of performing integrated change control. First off, what is "perform integrated change control"? Integrated change control means that if a change enters the project, it can affect the entire project.

So you're building a house for me and I come to you and I say, "Well, I know you're almost done or you're halfway done building this house, but I really want a three-car garage instead of a two-car garage." So just go ahead and bump out that wall and give me another bay in this garage because I want three cars. So you have to consider that change. It's a massive scope change. It's going to cost more to implement that, and you're going to need more time to finish the project. It could affect quality because it may have changed the aesthetics of the home or something could get damaged that you've already done, like the foundation. So it's going to affect quality, it could affect HR, because now you need to get more people involved to make that third bay. Obviously, communication, because you've got to talk to your project team, city inspectors, the architect, anything that's going to affect communication, could introduce some new risk, and probably procurement, because you're going to have to procure the concrete and materials you need to construct that bay. And then you're also going to have some stakeholder management. You're going to have to talk to the city, you're going to have to talk to the architect, your project team, and so on. So one change. I know it was a pretty big change, but any change, small or large, can have a ripple effect throughout the whole project. It takes time and sometimes it takes money just to entertain the proposed change.

So-called "integrated change control" is the study of a proposed change and what that change can do to your whole project. Now I said "proposed changes." It's possible that you could have a change that was not approved. That has already happened. Defect repair. The project team painted this room yellow; it was supposed to be blue. It already happened. It was a change. So now we have to deal with that change. We have to examine what ripple effect that change has on the project. So, perform integrated change control. Our first goal here is to ensure that only approved changes actually happen, that we don't want changes to sneak into the project that weren't approved. We want to prevent unapproved changes. We want to ensure that we're reviewing change requests promptly. We don't want to try to run out the clock by delivering the project when there's some pending change request. So we want to make sure those happen quickly and effectively. When the change is approved, it has to be fleshed out in the project plan, and then the project team has to implement the change. So we manage approved changes, we update the projectplan, and we probably update some project documents as well. When a change is approved, our baseline is likely to change in time, cost, and scope. So it doesn't mean that all three of them are going to change, but they could.

I mean, a scope change could cause time and cost. It's possible to have a change to just cost just time that doesn't affect the scope. The price of materials went up. The scope didn't change, the time didn't change, but we have to pay more for those materials. As a result, our baselines could change as a result of any change from any area of the project. We review, approve, or decline change requests. We don't have to approve everything. Now, your organisation may have some specific rules or they may have a change control board that does this for you. Whatever those enterprise environmental factors are, you have to adhere to them when a change is approved or declined, and we communicate the status of that to the stakeholders. So, particularly the stakeholders who requested the change. If it's declined, if it's approved, we tell all the stakeholders that everyone needs to know what's happening in the project. Now we also document the change request. We have a change log. The changelog has approved changes and declined changes. that all changes are documented in the change log. When the change happens, we implement that change across the entire project. So, whatever knowledge area it affects, we may need to update the plans and effectively communicate the change to the project team and stakeholders. And then the last point there, as I mentioned, is that you document the change request and its impact,and that goes in the change log. And then it can cause your project management plan to be updated and your project documents to be updated. So that's the big picture of performing integrated change control. Let's look at the EDOs for this process. I need my PM plan. I have work performance reports. How are we performing change requests? The actual change we're going to analyse, then EEF and OPA, some of those things I just talked about, like your procedures for how changes are approved or declined. Let me give just an example of an EEF here, so we're really clear. Your organisation could say that any change to your project that costs more than$10,000 to implement is automatically declined.

We won't make any change of that size or any change that will take longer than three weeks to implement automatically decline.We won't do it. So that's an EEF where it's a rule that those types of changes are too significant for a project. So those have to be a spin-off project or an addendum to the existing project. So you'll add it on later. OPA could be forms and templates that you use for change control. Now, tools and techniques here, expert judgment. You're going to analyse the change. So you need some smart people to help you make the best choice. You're going to have meetings because this is where you're going to discuss the change and do the analysis. And then we have some change control tools and that's just a nice way of wrapping up the analysis, maybe doing some testing or hypotheticals or designing experiments to see how this change affects the project and how it could realistically be implemented. Our outputs are here.

You have approved the change request. That doesn't mean every change request gets approved. We have a change log where we document the results of a change request approved or declined. And then, as I mentioned, the PM plan could be updated, and your project documents could be updated as well, as a result of a change request. Configuration Control: This is one that I get a lot of questions on, so I want to be really clear on configuration control. Let me give you a little story here, a little war story. A few years ago, I was doing some consulting for an electrical company, and at that company, they were updating all of the power sites, those big transformers and electrical equipment. And I'm not an electrician, so if you are, forgive my ignorance here on what these things were out in the field. So these little stations that you might see with the big fences around them, were going out and upgrading the equipment for their company to provide electricity to the community.

Well, the guys would go out into the field—the electricians and electrical engineers and professional engineers and so on—to go and update this equipment. And what was actually in the field did not match the blueprints that they had in the office. What happened years ago when they installed these different sites? The engineers that were installing the sites would change things a little bit on the fly. So what might make a little bit more sense based on their preferences or how they were installing the equipment? Well, it didn't match what they had in the office. So what was actually in the field was different than in the office. They didn't have field drawings where they updated the blueprints, so it's consistent. So they had a real problem. They had to go out and do an analysis on every one of these different sites to ensure they were updated, invalid, and then upgrade the system to make sure they had consistency between what wasactual and what they had in the office. That's configuration control. That's it's.Anything that deals with the features and functions is documented in that it is accurate. So if there's a change to scope, like they were changing the power plant or whatever that piece of equipment was in the field, it needed to be updated in the office. So configuration control controls any changes to the features and functions of the thing you are creating. So it's a specification about the deliverables and the processes to implement those deliverables. And then it's also how the project work is completed. When they were installing those pieces of equipment, they should have followed the plan as to how they were to be installed. If they had a legitimate reason to change the installation, that was a change request that didn't happen. So they should have not only gone through that process but updated the drawings to match consistency. So configuration control is about controlling the configuration of what you're creating and how you create it. Anything that affects the features and functions of the project scope must go through configuration control because we have to document that change clearly and make sure that we are doing the work the way the customer expects it to be done. And we need consistency. So, configuration control is about features and functions. Now, there are three terms tied to configuration control. First off, configuration identification. This is the identification and documentation of the product in its components.

So back to the electrical piece of equipment there,this would be the identification of what all of those parts do, how they're situated, and all of their components that contribute to the deliverable. So if we were to take away the electrical for a moment, this little remote control that I'm using, configuration identification would explain all of the different buttons. The contour of this device, the battery cover, the type of batteries, where the little USB stick goes, all of that is configuration identification. These are the features and functions of this device.

Just like that piece of equipment, it needed features and functions in order to be good and acceptable for long-term use and support. Then we have configuration status accounting. This is the documentation of the product information. So, was this contour, this battery cover, all these buttons, and the torque or pressure required to click in line with what was planned? So we need the status accounting documentation of the product information. Then we have configuration verification and auditing. This is all about the performance and functional attributes of the product. Is this operating the finished product as the scope called for the features and functions? So we have the features and functions of that piece of equipment out in the field. identification of the different parts, status accounting, the parts installed correctly and as planned. And then at the end, verification and auditing don't work as planned. It's all about the project scope, the deliverables, anything that affects features and functions.

Managing project change is really about four activities that you have to do or four things that you have to consider when managing project change. First off, you have to have documented change requests. Verbal change requests don't count on your exam. Someone asks you to make a change. What should you do? You don't do it. It's not in writing. I know in the real world that's not realistic. On your exam, though, it is realistic. You have to have documented change requests. Verbal change request, no good. It has to be in writing. Unapproved changes When you receive a change request and you look at it, you say, "We can't do this."

After you do your analysis, don't just throw it away. You communicate that we aren't going to do it. It's unapproved. And you add that to the change log. The reason why you don't want to get to the end of the project is And the CIO says, "Hey, where's this change I asked for?" Why isn't it in the finished deliverable? And they're upset. Well, you communicated that to the CIO and you have documentation that it was communicated and unapproved. So you need to be aware of that and communicate that as you move through the project. Now, two terms here: scope creep and Scope creep refers to the addition of minor changes to a project that are not approved. They bypass change control. So, scope creep is really something that you don't want to have in your project. Scope creep is really stealing from time and cost because you are doing things that are not in budget and they are not planned for on time. So you're working on things that are out of scope rather than in scope. In scope, creep is poor quality. It's also known as "project poison," because that's where you start to get cost variances, because you're working on things that are not in scope. gold plating. Gold plating is actually really bad. It's where you have an amount of money left over in your project budget.

So you begin to add features in order to consume the whole budget. So gold plating is actually spending money on things that were not approved. So sometimes you hear PM say, well, I go above and beyond, I go the extra mile, I under promise and over deliver. Nope, not any good. Can't do that. That's gold plating. You have to deliver exactly what was promised. If you think those changes are needed and you think they're valid, yes, you can create a change request and get them approved. If the customer wants them, The customer may not want them.

They may rather have what was promised to them because they can begin using that deliverable. So gold plating is just consuming the budget. In reality, that money could be used elsewhere in the company. It's not yours to spend on your project. As you see, you just can't add features to eat up the cost. Gold plating is not good. Finally, let's look at the change control system. The whole picture of change control and proposed change comes into your project. So the first thing you do is it has to go into the project management information system. The first part of the PMIs is to document the change, and then we're going to look at what effect this change has on scope, schedule, cost, or contract. In reality, I said that incorrectly. We're not looking at what effect it has. We're determining where the change originated from. So I got a little ahead of myself. So when a change comes in, we're saying, does this change come from scope, schedule, cost, or a contract? So that's typically one of those systems that I have mapped out there. That's where all change will originate from. If the change comes from scope, we want to add a feature or function. Then we do configuration management.

So the configuration management system examines the effect of that change on the features and functions. So that's where we get into all that configuration management business. Now, scope, schedule, cost, and contract changes then go through integrated change control. Integrated change control is where we say,what effect does this have on scope,on schedule, on cost, quality, HR, communications,risk procurement, and stakeholders? So it's the analysis of the proposed change. We haven't approved it yet. It may be too great to be approved. If we approve the change, let's say it's good and we approve it, it will then go into the change law.

If we decline the change, what do we do with it? right? We don't throw it away. It goes into the change log. The change then may cause the product scope to be updated. Remember, configuration management. If you want to add a third bay to your garage or you want to change those items to the field that's features and functions, the product scope could be updated. The project scope could be updated if it's a scope change, which would cause us to update our workbreakdown structure, which we haven't talked about yet. Our WBS dictionary, something we'll see in chapter five of the Pinball, and our project plan and project documents. So that's the big picture of a change control system. All of that information is critical for your exam. All right, good job. We talked a lot about how I know an awful lot in this lecture about managing change and integrated change control. So, good job. Keep moving forward. I'll see you in the next lecture.

8. Close the Project

We're now ready to close the project. Closing the project is usually the happiest day of the project because you've reached the end of the project and you're ready to close down the activities and move on to other things. Now, when we close the project, this process,remember, it's not just for the project. We can also do this for a phase. And the actual name of the process from pinballfour to six is to close the project or phase. So let's take a look at that now. Here we go. All right, so close the project or phasecontract documentation, we need to close it out. So what are the terms to close out the contract? So this is the idea that if it's a client-vendor relationship, if I'm building a house for you, we have to follow the terms of the contract. You've got to inspect it and sign off on what I've delivered and pay me. Now what could also happen here? We could have a vendor that's doing work for us, and they've done a poor job of living up to the terms of the contract. So we're going to terminate the project. So it could be an early closure, not always a pleasant thing. If we terminate the project early because of poor performance, then our contract documentation may specify how we cancel the project. How we cancel the contract is needed here.

It's not just as if everything were going well. There will be those instances where we have vendors that do a poor job and we want to cancel the project with that vendor. Enterprise Environmental Factors set the rules for how you close a project or phase. You may have some particulars that you have to move through, or maybe you're not the individual that signs off on the final inspection from the vendor. So who does that for your company? Who writes the check to the vendor, things like that? As part of Enterprise Environmental Factors,work performance information is needed here. We have data and then we analyse it. So now we have information. So work performance information is where we can look at how well our project performed in terms of time, cost, scope, quality, risk, and team performance. And we can really do an analysis of the entire project in all of the knowledge areas and see how we can improve in the next phase of this project, or how do we improve it? If we're at the end of the project, closing out the whole thing, how can we improve future projects based on this project's performance? We have the deliverables, the things that the project created, and then we prepare to archive. We don't just throw away all of our project records. That must be archived because it is part of the organisational process assets.

Let's look at the edo here, which closed the project or phase three inputs. The project management plan accepted deliverables and OPA tools and techniques, expert judgment, analytical techniques, and meetings as our outputs. Here you have the final product, the service, the result, and the transition of that result into operations. And then, as I mentioned, we don't throw away our project records. We archive it, and it becomes part of the organisational process asset update that it becomes future historical information. So what actually happens when we close the project? Well, we assembled the project record. We have to bring everything together and assemble it and make it easy for reference, whether this means electronically or physical files, probably electronically.But we assemble that to make sure everything is organised and that it's easy to find and reference in the future, because that's going to help you out in the future. We determine: was the project a success or a failure? Remember, way back at the beginning of this section, we talked about determining the factors for success in project initiation. How do you know if your project is a success or a failure? How do you know what constitutes good? How do you determine what constitutes acceptance? So now we're measuring whether the project was successful based on our goals we created at the beginning of the project.

We finalized lessons learned. So, lessons learned. Documentation happens at closing. Remember, it happens throughout the project, not just at the end. And then, finally, we archive the records. We don't throw it away. It's very important for your exam. All right, good job. I know this was a really big chapter. We talked about a lot of things in this chapter that you're going to see in the next lecture. You have a little break here. Take a little brain break. We have a little learning game about project integration management. So go ahead and hop out and do that now. You can see it in the next lecture. And then we'll continue to move forward. The next section is very important. It is all about project scope management. So I'll see you very soon.

9. Section Wrap

I told you it was a big section. A lot of information in there, right? A lot of important information for your exam. So I know this is something you're probably going to want to watch again, want to make sure you know these terms and these processes. At the beginning of the section we talked about how to choose a project. So are we doing this for an opportunity? Is there a problem that we're solving because a customer asked us to do it? Those are three big reasons why we choose a project. Then we look at, with each project, what is the future value of money? So I take this present value, this present amount, and then I can do that little formula where it wasone plus I, where I is the interest rate to the power not multiplied by three, but to the power of N, where N is the number of time periods. And then I could do the inverse of that, where instead of the future value, I want to find the present value. So what's some dollar amount in the future worth today? To find out the present value, we also looked at the past present value and the internal rate of return.

Our first process that we talked about in this section was to develop the project charter. It's our first of all of our project management processes to develop the project charter. And the big thing here is that the charter authorises the project to exist in the organisation and it authorises the project manager with a defined amount of authority. Then we look at developing the project management plan, where our project management plan is really a collection of plans. And remember that planning is iterative. So you might be coming back. You will be coming back to planning over and over as needed in your project. We talked about the purpose of the plan; we talked about how it communicates intent; it serves as a guide for the project manager; it gives structure to our project, documents, and decisions. And that's where we get our baselines. And there are three baselines. We have the scope baseline, the time baseline, and the cost baseline, which we'll be seeing in the next three sections. On scope, time, and cost, we looked at the process to direct and manage the work. So we're over an execution. It's all about getting things done and making sure that the team does the work.

This is where we spend the bulk of our time and the bulk of our money. It's where we do team development and where we do procurement. All those who carry out activities We looked at monitoring and controlling the project. That's done in tandem with execution, constantly on the lookout for new risk. And we're also maintaining information about our project's current state, knowing where we are in time and cost, any variances. So, keeping a keen eye on what's happening in the project, we also talked about performing integrated change control. That one change can have a huge effect on the project as a whole, so we have to make that change. Let's say a change comes in from scope. We have to look at that scope change, how does it tie into configuration management, the features and functions that may be changed, and then what happens to our time, cost, quality, human resources, communications, risk procurement, and stakeholders? So, perform integrated change control. It takes time just to do integrated change control. carry out integrated change management So, project change management We had two key terms for you that hinted at earlier scope creep and gold plating.

Scope creep refers to small unapproved changes that allow our scope to creep bigger and bigger and bigger, whereas gold plating refers to spending money in the budget just to consume it. These are not approved changes. We're just adding things to eat up the budgets. It's like we are dipping stuff in gold that doesn't need to be gold plated. Our last process, your favorite process, was closing the project, or phase one of our two-closing processes in all of the 47. So we talked about closing out the project and ensuring that we archived the information. You're doing fantastic. You're really taking the time and dedication to move through this. I want you to continue to be proud of yourself, that you are in trouble training. You're not training for it. You are in training to pass. Keep proud of yourself, keep motivated. You can do this. Let's keep moving forward.

Study with ExamSnap to prepare for PMI CAPM Practice Test Questions and Answers, Study Guide, and a comprehensive Video Training Course. Powered by the popular VCE format, PMI CAPM Certification Exam Dumps compiled by the industry experts to make sure that you get verified answers. Our Product team ensures that our exams provide PMI CAPM Practice Test Questions & Exam Dumps that are up-to-date.