PMI CAPM – Blitz Review of the CAPM Course Part 3

  1. Master Project Integration Management

We’re now going to talk about project selection methods, how to choose a project so quickly. We talked about future value. Future value is what some amount of money is worth in the future. And this formula, remember, was present value with one to the power of N, where I is the interest rate in N is the number of time periods. So it’s the present value times one plus I to the power of N. The opposite of that is the present value. It’s what some amount of money, what someone promises their project will be worth in the future, what is it worth in today’s? Dollars. And instead of multiplying, we divide because we’re reducing it. We’re bringing it closer to today.

So present value equals future value divided by one plus I to the power of N. Another project selection or benefits measurement was net present value. You probably won’t have to do this calculation. It finds the present value for a project where each year your project gives a return. So year one through five, each year find the return, the present value of that return, add it up minus your original investment, and basically anything better than one is really good. What about developing the charter? We talked all about the charter. It’s a partnership between organizations. A charter can be a contract.

It formally initiates your project, names the project manager, names the sponsor. It authorizes the project manager and the project to exist. Some facts about your charter why are we doing the project? How do you know when you’re done? What am I supposed to do? Yes, the charter does list assumptions and constraints, gives a big picture of the project, what’s in and out of this project, and any obvious high level risk. Your project charter also may provide your milestone schedule or just some goals for the milestone. What’s the budget or a summary budget? Who are the stakeholders? Really important. How do you know you’re successful? Who signs off on the project? And it also names the PM, as I mentioned, and the authority level and the project sponsor.

Project Planning every knowledge area has at least one plan. So planning as well as ongoing, it’s just you don’t do it once and never come back to it. So as more information becomes available, you can plan in more detail that’s progressive elaboration. Remember the idea of rolling wave planning. And remember the idea of checkpoints like phase gates or phase gate estimates. That’s part of rolling wave planning. Look at all the stuff that’s in your project plan. Okay? Change Management Plan who you’re going to talk to? Communications configuration management plan.

Cost baseline. A cost management plan. HR management plan. Process improvement plan. Procurement management plan. The scope Baseline quality management Plan requirements management plan. Risk management plan. Schedule baseline schedule management plan. Scope management plan stakeholder. Management plan. Okay, now, on your exam, you’re going to get a question as to which one of the following aren’t part of the plan. I mean, it’s not going to be that easy. It’s going to be more like a scenario. And they’re going to describe which plan would guide you on this activity. So based on the activity, you would have to know which plan are we talking about here? So know the characteristics of these plans. We have some actions that you have to take in the project real quick here.

Corrective actions. So you got to fix a problem, get the project back on track. Preventive actions. You don’t want a problem to happen, so you’re going to fix it and make sure it doesn’t happen again. Could require a change request. Corrective preventive and defect repair. So defect repair is kind of like a corrective action, but you’re going to fix a portion of the project. What to report? You got to do a lot of work reports, different types of reports and information. People want to hear from you. They want to know what the heck’s going on in this project. So we talked about work performance data. Remember, this is just the raw data, just real quick facts.

Lowest level of data, not a whole lot of usable information as it is. You have to analyze it, and that’s when it becomes work performance information. So the data becomes information. Data can’t be used in decision making. It’s just raw data. You have to analyze it and see what it means based on your information. Then you can create a report. So it’s a physical or electronic representation of work performance information. Basically, it’s a report. Okay, so you have data, information, report, in that order. It’s alphabetical data information report. A big process, very important. Integrated change control. Recall that. Integrated change control is what I look at when a change is proposed because I’m examining what effect does the change have on the whole project. So when that change comes into the change management system, I want to see what effect does it have on the whole project? So I’m going to look for approved changes. They don’t want things to happen without an approval.

They need to be documented. I want to review those quickly and then I manage those. I’ve got to communicate it. I’ve got to incorporate it into my plan and ensure that it’s been done. If a change happens, it may affect my baseline. Do you want to add stuff to scope? I need more time, more money. Baselines are going to reflect that. Changes that are declined, we don’t throw away. They still go in the change log and the reason why they were declined. Part of our integrated change control was configuration control. So we had identification. It’s the ID of the product and all the components. So basically, what is all the stuff you’re getting? Configuration status, accounting. That’s just the documentation of the information that’s in the product.

Verification and auditing. Is it performing well? Are the functional attributes correct? Big picture here of change control. What you see on your screen highlighted in orange, that’s what we’re looking at with integrated change control. So you can tell it’s every knowledge area we look at. Okay, here comes the change. I know you love a change that’s entered into our PMIs. Changes are going to come from scope, schedule, cost, or contract. If it’s from scope, we go into configuration management, features and functions, configuration management. Integrated change control is where the change passes through scope, schedule, cost, or contract, and we look at the whole project. So what does a change in time do to all of these things? What about a change to cost or scope or so on? The outcome of that analysis is entered in the change log. Approved or declined goes in the change log.

If it’s a scope change, I’m likely going to have to update the product scope and then the project scope, the WBS and WBS dictionary, and then the project plan so that’s integrated change control the whole picture. All right, I know we’re moving quickly. Remember, this is a blitz, so we’re going fast as we can. Just a quick review. If you want more information, you want more details, you need to go back into the course, into the chapter on integrated change control or whatever chapter we’re talking about. We are moving fast, so I’m going to move on here. You got to close out your project. So this is right out of the Pin box. You’re going to close down your project or phase. You don’t have to wait to the very end of the project to do this process. You could be closing out different phases.

We also close out contracts. When we close out a contract, you might have to do an audit. You might have to do some negotiations if you’re having an early termination. So you have things like issues or claims or disputes. Remember, when we have a dispute, it’s preferred to do alternative dispute resolution. We would rather do some ADR than the alternative dispute resolution than to go deal with an attorney. Sorry, attorneys closing procurement. So we’re all done. We close out procurement. We have a procurement file. We have deliverable, acceptance and lessons learned. All right, good job finishing this lecture on chapter four on project integration management. Yep, we’re going super fast. I will see you in the next blitz.

  1. Explore Project Scope Management

Okay, welcome back to our conversation. Here our blitz conversation. We’re going to talk all about project scope management. Just the major stuff, the important stuff here in scope management, the scope management plan, that’s pretty important. It defines how will you create the scope statement, how will you make the WBS, how will you maintain it, how will you do formal acceptance of scope validation and how will you control scope changes? We also have a requirements management plan and this defines how will you analyze requirements. So how do you know these requirements are what you need? What’s the documentation requirements? How you manage them? What about phase to phase relationships where you don’t really know what’s going to happen in the next phase? You got to pause and do some planning, or you’ve got phases that are iterative, or they overlap, or you’re doing fast tracking. So how does that affect requirements? You have to get out and collect requirements. So that means you got to get out and talk to people.

So remember we had the stakeholder register? It’s a directory of all of our stakeholders. And then we talk to people one to one, one to many to many, all the different ways you can talk to folks. There a focus group, a moderated event with up to twelve people. Get yourself a neutral moderator to manage the focus group and have the correct participant composition. So whatever you’re after, you might have a distribution of resources from all over your company, or you might just have folks from one department. Whatever your goal is, you might go off site and do a facilitated workshop to gather requirements. Sometimes. This is called a joint Application Design workshop. Probably the most important tip on this slide group decisions.

Oh, there’s nothing better than management by a group. So group decision. It’s unanimous. Everyone agrees. The majority, more than 50% agrees. The plurality is the largest block. With the plurality, you could have more people collectively opposed to the decision than in favor of decision. A dictator. Whoever is the dictator, the power decides. Really important stakeholder observation. Remember this job shadowing. And then we have passive where you just sit and watch and active. You are involved. So stakeholder observation prototypes.

You have a throwaway prototype like on this napkin, a functional prototype. You can actually use it. Whatever your prototype is, you can incorporate it into the solution or storyboarding. A context diagram is another way to gather requirements. It’s an illustration of all of the working components. So think about your network. It would illustrate where the servers are. What do they do, how do they talk? With workstations, databases, the flow of data, your workflow, and then people. And people are sometimes called actors.

In a context diagram, what’s in the scope statement? Lots of good stuff here. Let’s take a look. All right, how do we define it? Well, you get your favorite people involved. Consultants, SME’s, maybe some industry groups. All those folks. All right, that’s fascinating. It’s all expert judgment, project charter versus the project scope. Charter all about authority. It’s all about high level. It’s all about getting started and who’s in charge. Okay, that’s great. Got to have a charter. Scope, though, is very specific. So we have project scope description acceptance. How do you know you’re done? What deliverables come out of the scope? What is excluded and what constraints and assumptions are you working with? Create the work breakdown structure.

Well, you know, the WBS, it’s a decomposition of the project scope. It’s deliverables oriented. It’s a major part of the scope baseline, member of the scope baseline. We have the scope statement, the WBS, and the WBS dictionary. How do you create a work breakdown structure? You get someone else to do it. And if that won’t work, you first define your major project deliverables. You structure and organize it by phase, by different major components. Like in our house project upper level components. And then you break that down to lower level. So the house first floor.

From the first floor, we have the master, the living room and the kitchen. You give identification codes called the code of accounts, and then you verify scope decomposition. Sometimes you have to let it cool off and then come back to it and continue. WBS templates. Not going to reinvent the wheel. Use one from a past project. The WBS dictionary, it’s all the stuff that identifies the pieces of your WBS. So it’s all the major attributes of what’s in the work breakdown structure. Validate the scope, you want the customer to accept your work.

So this is inspection driven with the customer, and they’re out there poking and prodding and kicking the tires, doing a walk through, just making sure that what you created is what they asked for. Sometimes an intermediary person will do this like an inspector for the city, like on the plumbing and the electrical work. The goal is I want the stakeholders to accept the work that we’ve created. You might have change request, but the goal here is you want people to accept what’s been created by your team for your stakeholders. All right, good job. Brings us to the end of that goal. Quick, super quick, high level review of our chapter on scope. Chapter five in the pinball.

 

img