CompTIA Project+ PK0-004 – Managing the Project Integration part 2

5. Monitoring and controlling the project work

As a project manager, you’ll have to be involved with your team to monitor and control the project work. You’re working with the team to ensure accuracy and quality. So you’re comparing actual experiences to the project management plan and that is the key takeaway with monitoring and controlling work. What did you plan to do and what actually happened? This allows you to assess project performance, identify risk, and then just to maintain information about where you currently are in the project. So this is a project management process. You’ll need the project management plan, schedule forecast, remember earn value management, cost forecast, validated changes, work performance information and then enterprise environmental factors and organizational process assets tools and techniques, expert judgment, analytical techniques, project management information system and meetings.

Now your outputs will be change request work performance reports, project management plan updates and project documents updates. Enterprise environmental factors will describe the rules and the requirements within your organization. So things like government and industry standards, your company work authorization system, risk tolerances, your project management information system that you’re required to use. So enterprise environmental factors are anything that you’re required to do. Now recall that organizational process assets are things that have been created for you to help you manage the project better. So you may have communication requirements like specific forms. You probably have some forms for procurement issue and defect management procedures.

Change control like maybe that’s already been established or is there some governance. Same thing with risk, you might have a process measurement database, especially if you participate like in Six Sigma. A process measurement database allows you to look at how well the processes are performing over time. And then you have lessons learned database where you can query past lessons learned forecasting project performance. Remember earned value management. We talked about schedule forecasting with estimate to complete the schedule variants and your SPI how well the schedule is performing. And then with cost we also had estimate to complete the estimate at completion and then cost variants and the CPI you.

6. Performing integrated change control

As a project manager, you probably know that change is inevitable in a project. Well, integrated change control is a project management process to ensure that only approved changes enter the project. It also looks at that effect, effect that that project has on the entire project. So it requires you to review change requests promptly and then to manage those approved changes, to get those changes that are approved into the project plan, and to update the baselines time, cost and scope. It’s also a requirement of integrated change control that not only do you approve and review change requests, you may actually have to decline and then you have to document and communicate that decline of a change request. Not always a fun activity to do. You’ll coordinate changes across the project and then document the impact of those changes for each knowledge area.

We’re going to look at that in one moment. So performing integrated change control, the inputs here you’ll need your project management plan, work performance reports, the actual change request, and then enterprise environmental factors and organizational process assets, tools and techniques, expert judgment meetings and change control tools, which is why we’re talking about some analysis here. Outputs. You get the approved change request, the change log. You have to update your project management plan and update the project documents. If you think about that, it makes sense, let’s say that we add something to scope. Well, you’ll have to update the plan to incorporate that into scope documents.

You’ll have to update like the work breakdown structure and the WBS dictionary as well as probably a host of other documents depending on what that change actually is. That’s been added to scope. When we add things to scope, specifically things that end up changing the product, then we have to do configuration control because this is the specification for the deliverables and the processes. Anytime you change features and functions of what you’re creating or how the work is completed, it’s configuration control. There are three terms you need to know with configuration control. The first one is configuration identification. It’s the identification and documentation of the product and its components. So this is typically done at the beginning of the project.

Part of our requirements gathering, a business analyst may do this for you, but it really describes what it is that we’re creating and that’s often called the product scope. And then you have configuration status accounting and this is the actual documentation of the product information. It’s more granular. And then you have verification and auditing and this is where there’s an inspection and it’s all about performance of those attributes of the product. Now, managing project change is almost always inevitable. Stakeholders are going to ask for more features. They’re going to ask you to change colors. They’re going to ask you to add fields. Just all sorts of business is going to come up with change requests. Change requests have to be documented.

Verbal change requests are not valid, you have to document them. Very important. So if a stakeholder wants something changed in the project, they typically have to begin the change process by documenting it. If it’s not documented, it’s not valid. Now, I know what you’re thinking. What if the CEO comes to you and they say, we want this change? Well, probably that change is going to happen. But someone, whether it’s the CEO or more likely you, are going to have to document that change. Now, any change that is not approved, that it goes through the process and it’s evaluated and it’s not approved, you just don’t get to throw it away. You have to document that and communicate the unapproved change. Because here’s what happens if you don’t.

If someone asks for a change and it’s declined and you get to the end of the project and there’s no documentation, there’s no follow up, that stakeholder is going to say, hey, where’s that change that I asked for? So you document it and communicate it. Scope creep is remember, it’s those little tiny additions that come into your project. It’s like you start off with you’re going to make a cheese sandwich and then you add a tomato and then you add this and this and this. And before you know it, you’ve got this giant massive sandwich. Same thing happens in our projects. We have a defined scope and then these little changes start sneaking in and that’s scope creep. And scope creep is really a poor quality because you’re creating things that are not in scope.

And scope creep robs us from time and cost that were to be designated for things that are in scope. And then we call gold plating is where we begin to add things to the scope. That just because we have money in the budget. So gold plating is also poor quality. Now we’re going to take a look at integrated change control. When we think about integrated change control, I like to start with the idea of integration. And so you’ll see this little box kind of plug into the rest of the flow chart in a second. But the scope schedule, cost, quality, human resources, communications, risk, procurement and stakeholders, these are our knowledge areas right out of the project management body of knowledge, the Pinbach guide.

And whenever a change is introduced, a simple change could affect every one of these knowledge areas. And so as we walk through this, you’re going to hear me talk about integration management. This is what I’m talking about, that it’s integrated throughout the project. That what I do in one area could affect all of the other areas. So let’s look at the flow chart and we’ll see these begin to snap into place. First off, we have the proposed change. That change needs to be documented and typically it just goes into your PMIs. Now the Project Management information system allows you to route that change through one of four subsystems now these four are all part of integrated change control. But almost every change, every change is going to come from one of these four.

So you’re going to have scope. I want new features, I want new functions, I want to change the colors, what have you. Schedule. There’s a delay in the schedule cost. We need more money or contract. We work with the vendor, we need to change the contract. So almost all changes will come from one of those four. Now anything that goes through scope goes through that configuration management. Remember, anything that changes features and functions, you have to document it and do some accounting on it. And so configuration management comes in. Now the change request is routed through integrated change control. And really, scope, schedule cost and contract, that’s part of integrated change control.

So this is where I started our conversation, that integrated change control is the examination of a change from scope, schedule, cost or contract and what effect does it have on the remainder of the project management knowledge areas. So let’s just take an example. You’re building a house from me and I come to you and I said, hey, great house, we want to add a little sunroom to the back of the house. And you’re like, all right, well, let me take a look at it, let me examine it. So that changes the scope. So from the scope, then you have to do some configuration management. So like the blueprints and whatnot and the requirements. Then you would look at integrated change control. You would say, well, yes, the scope changes, the schedule is going to change, it’s going to take a bit longer to do the work. Costs are going to change because we need more materials. Quality, does that affect the quality? Well, the architect may stand back and say, this just doesn’t look good with the rest of the house. It’s not the vision that I had for the house. So quality could be an issue, HR could be an issue because now you have to bring resources back to the project. Communications, probably have to get an inspector, probably have to get a permit, your project team, so there’s lots of communications that could happen with that simple change risk. It could introduce some risk in the project. You have to knock out a wall and you have to do some foundation work. And so there could be some risk just to create this little sunroom. Procurement is going to happen. You’ve got to buy new materials and then stakeholders.

So your project team, that architect, the city inspector, me, the customer, so stakeholders could be affected, that’s integrated change control. It’s the evaluation of the change on all knowledge areas. Now it’s possible that you could have a schedule change that doesn’t affect anything else. You could have a contract change that doesn’t affect anything else. But regardless, integrated change control requires us to look at all of the changes and then the outcome of that is to document it in the change log. So an example I gave about adding this little sunroom that was the scope. So the product scope is updated and then the project scope is updated and then the WBS and dictionary is updated and then you have to flushed that into the project plan. That is the entire change control system. It’s integrated into control.

7. Section wrap

Save it for the end of the course rather than early in the course. This is actually chapter four of the Pinbox, but because it’s so integrated with all those knowledge areas, I often like to put it at the end of this course. Now, project integration management begins from when the project starts. So that’s why the first process was creating the project charter. The charter authorizes the project project and it authorizes the project manager. The charter then allows us to begin moving into integration management. We plan the project, we then execute the project, monitor and control the project, and then close the project. And that is the project management lifecycle. Recall that the project management lifecycle is a way of showing how you move through the project management activities and their iterations. So it’s not a straight sequence that you move to the most appropriate process in the most appropriate process group.

So for example, you’re in planning, you’ve created a project management plan. Your team goes about executing the work and they notice a new risk. Well, that new risk then would allow you to go back to planning to plan risk responses. So there are iterations here. It’s not a straight sequence. That’s the project management lifecycle. Now, the project lifecycle is unique to every project that you do. So if you’re in construction and you’re building a house, that life cycle of building the house would follow those phases of the foundation and then framing, electrical, plumbing, interior and so on. So the life cycle is the project work. The project management lifecycle is universal to all projects, but it only addresses how I act as a project manager, initiate, plan, execute, monitor control.

In closing. Now, another important process that you must know for your CAPM is project integrated change control. Integrated change control tells us that whenever a change is proposed in the project, so whether that be a new scope change, cost increase, a schedule change, or a contract change, it flows through integrated change control. And what that integrated change control is? It’s the examination of that change on the entire project. So let’s just say that a change comes in cost. You’re building that house and your customer says, I’ve changed my mind. I want a three car garage instead of a two car garage. Well, that obviously changes scope, it changes the schedule, probably going to change cost. The quality is going to change because our requirements have changed.

The architect may have some things to say about the quality from quality or HR changes. We need people to do the work. Communications probably have to communicate with the architect, with the city inspectors and so on. From communications we have risk. Does that introduce a new risk? How does that affect the structure? And then we get into procurement. I have to buy materials to build that third bay and then stakeholder management. So there may be some lot of stakeholders that are affected by that decision. So one decision can have a ripple effect through the entire project. And that’s a really important concept for your exam, is integrated change control. All right, great job. You made it to the end of this really important and really big topic about project integration management.