PMI CAPM – Plan, Assure, and Control Project Quality Management for the CAPM
Section Overview So, what exactly is quality? So many people talk about quality, but it’s never really defined. We’re going to define quality in this section. In order to achieve quality, everybody has to agree on what quality is. So, in this section, we’ll look at what quality is, as well as quality planning and management. So we’re talking about defining our quality policy and our quality assurance. And then, how will you do quality control? The quality management domain consists of only three processes: quality planning, quality assurance, and…
So, what exactly is quality? So many people talk about quality, but it’s never really defined. We’re going to define quality in this section. In order to achieve quality, everybody has to agree on what quality is. So, in this section, we’ll look at what quality is, as well as quality planning and management. So we’re talking about defining our quality policy and our quality assurance.
And then, how will you do quality control? The quality management domain consists of only three processes: quality planning, quality assurance, and quality control. So it’s a pretty short chapter here. It’s a very approachable chapter on quality. We’re going to look at the difference between quality and grade. If I buy a better grade of steel, does that mean the quality of my project is going to go up? Is it better quality because it’s a better type or grade of steel? An interesting topic All right, maybe not, but we’re going to look at that. In this section, you’re going to learn the difference between quality and grade.
So it’s all about quality project management. It’s about understanding what constitutes quality. Customer satisfaction is central to quality. So we have to then conform to those requirements. That’s how we achieve quality. It satisfies the requirements and is fit for use. Now, a theme throughout this section will be that quality is planned into a project.
It has not been inspected. Quality is built in, not inspected out. There’s a management responsibility to achieve quality. And so if management says zero defects, that’s okay. As long as they give us the avenue, they give us the tools to reach zero defects. A conversation we’ll have in here as well is on dimming. So I want you to look for Dimming’s plan, do it, check it, and act on it. We’ll see that in this section. Really important. I’ve talked a little bit already about regulations in this course. Well, regulations are requirements.
So to have quality, you have to adhere to regulations. Standards affect quality as well, but standards are optional, whereas regulations are not. So we’ll look at that. We’re going to talk about the cost of quality, sometimes called the cost of conformance to requirements. And we’ll talk about the cost of poor quality and noncompliance with requirements. So some important information on those two topics Watch for these seven basic-quality tools.
You want to be able to recognise these seven basic quality tools for your exam. So here they are. Cause-and-effect flow charts, check sheets, parental diagrams, histograms, control charts, and scatter diagrams We’re going to look at those in this section. We’ll also talk about benchmarking the project and designing experiments. And then we’ll get into quality assurance, where we’re ensuring that quality is built into the project. And then quality control, inspection-driven, goes out and inspects the deliverables. Just three processes, but a lot of information in this knowledge area. So this is chapter eight in the Pinbach Guide. We’re going to go in here now and knock this out so you can do it. Keep going. Let’s get started right now.
We’re now ready to talk about planning project quality management. This idea of creating a quality plan means that we are planning to achieve quality. That quality is always built into a project. It’s planned into a project; it’s never inspected into the deliverable. We do the work right the first time to ensure that quality exists in our project endeavor. So let’s take a look at the quality management plan and the process improvement plan that we get as a result of this process. So we are defining the project’s quality policy based on the Pinboc eight-point plan for quality management. that we are defining our quality assurance requirements and how quality control activities will occur.
In our EDO for plan quality management, we have a lot of inputs and a lot of different tools and techniques. We’re going to look at this idea of creating the quality management plan by inputting the project management plan, the stakeholder register, the risk register requirements, documentation, and EEF and OPA tools and techniques. We will look at cost-benefit analysis, the cost of quality, and seven basic quality tools in this section. We’re going to talk about benchmarking the design of experiments, statistical sampling, some additional quality planning tools, and your favourite meetings. So we’ll look at all this coming up in this lecture. The results of quality management planning are now available. I got the quality management plan and the process improvement plan. We’ll have some quality metrics and a quality checklist, and you may have some updates to your project documents. So let’s talk about the quality management approach that we want from the top down quality. What this means is that from management on down, we have a focus on quality. It also means that we have to define exactly what quality is quality. That we don’t want to use these ambiguous terms like quality, and people are happy, and it’s a little more subjective that we want some quantified terms like fast, good, or reliable, for example. So top-down quality is a management-driven approach here in that it is built into the project; it’s not inspected in. When we talk about quality, we also have to be aware of two particular things.
One is that we don’t want to overwork the project team. It’s not healthy for the project, and certainly not for your project team members, to make people consistently work overtime. So they’re working 50 or 60 hours every week to get things done, and people are going to have some resentment very quickly for that type of schedule. And that’s going to cause not only morale to suffer, but it’s going to cause quality to suffer. And then we don’t want to speed through quality inspections. So if you have two weeks set up for UAT (user acceptance testing), we don’t just cram it into three days. This will allow some escaped defects to enter our product because we do quality inspections with care and caution, and we do them properly regardless of what’s going on elsewhere in the project. You know what happens: there’s never enough time to do the work right the first time, but there’s always enough time to do it over. Well, nobody wants to do their work over. So it’s better to take your time and do the allotted quality inspections. And we aren’t rushing through those. I mean, haste makes waste, and that’s what happens when we rush through quality inspections, something that we don’t want to happen in our project. Now, a term that we need to nail down here, and perhaps you already know this, is the idea of quality versus grade. Quality is really kind of an esoteric term.
So, what exactly is quality? Quality is the totality of an entity that reflects its ability to satisfy stated or implied needs. It sounds like an attorney wrote that. But, in reality, quality is all about meeting requirements and giving the customer exactly what they asked for—no more, no less. So it’s about satisfying the project scope, satisfying the product scope, and any of those implied needs that come along with, “I want you to create a piece of software for me,” or “I want you to build a house for me.” There are some implied needs. This isn’t saying that we just allow assumptions into the project. There may be some assumptions we just have to have, but it’s saying that you really have a fitness for use, that you are conforming to requirements, but you’re also delivering something that’s fit to be used. Now, grade is not the same thing as quality. You can’t say, “Well, I’ll make it better; I’ll make this deliverable better by using better materials.” The customer may not have asked for those other materials, or the materials that you’re providing may drive costs but not necessarily improve quality. So, for example, if you have a mouse on your desk, is it going to work better just because it’s made out of gold? It’s not worth the money to have that mouse operate; it doesn’t necessarily improve the quality of that mouse, that service, or that thing. So grade is often what we’re talking about when we think we’re talking about quality. Quality is the fulfilment of requirements. Grade is a category or ranking of services or materials.
So if you think about your grade, you could be in first class or you could be in coach. If I’m going on a real trip, like I live in Florida, it’s about an hour’s flight from here to Atlanta. If I’m just going to Atlanta and I really don’t want to fly first class, I’ll just go by coach. It’s not the most comfortable thing, but I save quite a bit from having to be up in first class, and I can have a quality experience based on my expectations of what’s going to happen in coach. I save money. I still get there at the same time. It’s only about an hour’s flight, so it’s not a big deal. But if I’m flying from here in Florida—I live near Tampa—all the way over to somewhere in Belgium, probably going to be more inclined to spend a bit more and go first class. So it’s a grade, a ranking of services proportional to what we pay for them and in line with our expectations. My point is that grade has no bearing on quality. I can have a quality experience in coach based on the requirements, and I could have a quality experience in first class based on the requirements for that experience in first class. So grade and quality are not the same thing. Low quality is always a problem. Low grade may not be low grade; it may be exactly what’s called for and exactly what’s needed. We have some terms to nail down here. Accuracy, precision, and quality Precision is a measure of exactness. Accuracy is an assessment of correctness. Precise measurements are notnecessarily accurate measurements. Accurate measurements aren’t necessarily precise measurements. I know that sounds really confusing, right? So let’s draw a little analogy here.
Okay, this little bullseye in the corner? So you and I, along with our friend Sally, will take out our bows and arrows and shoot some arrows at this bullseye. So Sally goes first, and she fires five arrows at this target. And when she hits this target, all of her land gets really tightly packed together in that upper right corner. I mean, she’s really just kind of drifting up to the right for whatever reason with her arrows that she shoots at the target. So she’s pretty precise. They’re all clustered together up in the corner, but she’s not really accurate because our goal is to hit the bullseye, that yellow bullseye. So exact to the measure of exactness. She consistently hits the same spot, but it’s not accurate. It’s not correct because our goal is to hit the bullseye. All right, so I’m up now, and I shoot my arrows, and I’m adjusting every time, and I’m all over the place on this target. In fact, one of my arrows missed the target entirely. I’m not very good at shooting bows and arrows or whatnot. So I am not very exact. Mine are all over. They’re pretty sporadic. And I only had one that came close to the bullseye, so I’m not very accurate either. So I’m all over this target.
Now. You take your five arrows and boom, boom, boom, right down, right in the centre of this target. That yellow bullseye So you’re very precise. All of yours are within just a few inches of each other in that yellow area, and all of yours hit the goal. So you are precise, all-clustered, and accurate. It was an assessment of your correctness. So much precision is in your exactness. like they’re clustered together. Your accuracy is also hitting the goal. So accuracy and precision are not the same thing. You can be precise but not accurate, or you can be accurate but not necessarily precise. So you could all be in that yellow zone, but not necessarily grouped together. So, quality project management Some things to think about with quality project management: it’s really all about customer satisfaction. Customer satisfaction means we have conformed to the customer’s requirements. And the thing that we create is fit for use. Quality project management is also about prevention. That quality is planned into a project; it’s not inspected into a project. Then there’s the management responsibility to meet our quality targets. So, for example, you’re a software developer or PM over a software development project.
And management says we can have zero defects in this software. You’re releasing, and that’s fine. Management could set that goal. But if they set that goal, they have to give us the mechanism and the time to achieve that goal. It has to be in proportion to what it would take to have zero defects in the software that you’re creating. So there’s a management responsibility above the project manager to achieve whatever the quality goals may be. Quality project management is also based on dimming. Dimming went to Japan after WWII and helped rebuild much of the Japanese economy. And he worked with the equivalent of the American Society for Quality, which was the quality engineers in Japan, to help rebuild Japan after World War II. So Dimming has a lot of theories, and he’s kind of the grandfather of quality. But one of the theories that we need to know for your exam is PDCA. And this is dimming’s quality circle of plan, do, check, and act (PDCA).So that describes what we do in terms of quality. We plan for quality. So we plan it into our project, we do it, we execute, and then we check it, monitor it, and we control it. And then, based on the results of our analysis, we respond. So then we act. Do we have to go back into planning, or can we move forward with the project? So plan, do, check, act (PDCA).Some additional thoughts on quality project management The first one is Kaizen Technologies.
Kaizen technologies are just kaizen, which means that we have continuous, small improvements to reduce cost and ensure consistency. The idea of Kaizen is that rather than having broad, sweeping changes in an organization, we make small changes continuously to lead to the result that we want. It’s easier to make a small change than it is to make a large, sweeping change. A great example is your training for a marathon. On day one, you probably don’t go out and run 26.2 miles. You might go run 3 miles, and then the next day or the next week, you bump that up to 3 and a half miles or 4 miles, and so on. So you’re making these little bite-sized changes to your life, your training, or your organisation to get to that end result. So Kaizen Technologies, or Kaizen, is just making small improvements to reduce cost and ensure consistency. Then we have marginal analysis. Marginal analysis is where we study the cost of improvements to see how those costs will contribute to an increase in revenue.
So we look at what the marginal cost is just to create one more unit, and one more unit, and one more unit. So a great example of marginal cost is what we talked about earlier: we had that small engine when we looked at some value engineering. So in marginal analysis, we say, “Can I improve the product?” Can I spend five cents more to improve this product? which would allow us to sell X number of more units. So, if I reduce or increase my cost by $0.05, I’ll sell X number of more units that are worth much more than if I hadn’t made this small improvement. So that’s a marginal analysis. We also have to think about determining the quality policy. We want to think about our formal quality approaches.
So like an ISO program, Six Sigma, or Total Quality Management, ISO is a pretty common one. It’s right out of the pin box. You might see this on your exam. ISO is Greek for uniform. It means that you do the work the same way over and over again to get the exact same result. So that’s a quality policy. It’s not a quality improvement, but it’s a quality policy. If your organisation does not have a quality policy, then it’s up to you, the project manager, to create a quality policy.Standards and regulations do affect quality. Standards, as you know, are optional. It’s a good guideline; these are the best practices. So I’m sure in your discipline you have some standards, guidelines, or just best practices. You might occasionally do things a little differently just based on the scenarios in your project, and no one gets in trouble for that or goes to jail for that or has to pay a fine because those are standards. They’re optional. However, regulations are requirements. Regulations are laws that affect certain disciplines or industries.
So you consider pharmaceutical companies and, of course, construction. We have a lot of regulations and requirements about how we build and construct and have to abide by the code in our state and where the construction may be taking place. Let’s talk about the cost of quality. This is from the Pinbock eight, one, two, and the cost of quality. First, there is the cost of meeting requirements. We’re talking about things like safety measures or training, having the right materials and tools, and having the right processes. It is the amount of money you must pay in order to achieve quality in your project. So that’s the cost of quality, and then we have the cost of nonconformance to quality or the cost of nonconformance to requirements. This is what happens if you don’t achieve quality. So, if you don’t have safety measures in place, someone could get hurt and lose a limb. So that’s your liability: you might have to do rework if your team doesn’t have the right competency levels, or your reputation could suffer, and you’re going to lose business. So the cost of conformance to requirements, sometimes called the cost of quality, is the money that you have to spend in order to achieve quality in your project. If you don’t have quality, you’re going to incur the cost of non-conformance, also known as the cost of poor quality. This section on planning quality will contain a lot of information. Let’s keep going. In the next section, we’re going to talk about the seven basic quality tools and how you can use them for quality assurance and quality control. So I’ll see you in the following lecture.
In this lecture, we’re going to talk about the seven basic quality tools. And as I mentioned, these can be used for quality planning, quality assurance, and quality control. So what are the seven basic qualities of tools? We have cause-and-effect diagrams, flowcharts, check sheets or checklist pareto diagrams, histograms, control charts, and scatter diagrams. So we’re going to look at each one of these. First off, there is a cause-and-effect diagram. It’s also known as an ishikawa diagram or a fishbone diagram.
What happens here in a cause-and-effect relationship is that we have the effect, the problem to be resolved, and then you have these things that branch off of it, the major causes, and then you can branch off again, and those can be contributing causes. What this ishikawa, or cause-and-effect diagram, allows us to do is It facilitates a conversation to find out what the causal factors are for this problem. So, for example, we could say we have a piece of equipment.
Let’s go back to that printing press. And because of the printing press, some of the images are kind of shifted from where they should be. So when we cut the paper down to the size of the image, it’s missing. The paper is being cut into the image instead of around the image. So something’s happening in our process here. So we go out and do some analysis, and we say, “Well, this always seems to happen at the night crew, or it always seems to happen towards the end of the month.” So those are some major causes.
Then we could say, “Well, we’re contributing to causes.” What about when we use a particular type of paper or a particular press operator? Or if we’re doing this and the machine hasn’t been through maintenance in the last 15 days or whatever the case may be, I’m just kind of making this up. But all of those could be major causes or contributing causes. So it facilitates a process to begin to narrow down what the likely cause of the effect is—the problem that we’re trying to resolve. So it’s an ishikawa or a fishbone. Then we have flow charting. Flow charting just shows how you move through a system or a process. So in this example, it could be for order fulfillment. What are all the things that we have to do, and where does the data go? What’s the flow of the work in order to get to the order fulfillment? So that’s a flow chart. It’s just an opportunity to see whether there are bottlenecks, whether there is a breakdown of the system, or whether we have some redundancy or some problems in our flow. So it helps us analyse the quality of the experience. a Peretto chart.
Peretto was an Italian macroeconomist, and he’s famous for working in his pea garden. That’s what he was famous for. And in his pea garden, he noticed that 80% of his harvest came from just 20% of his pea plants. So that’s where you get the idea of Pareto’s law, where 80% of your business comes from 20% of your customers. Or if you’ve ever worked on a help desk, you know that 80% of your calls come from 20% of the people. So that’s Peretto 80 20.
Well, there’s a Pareto chart that shows the distribution of problems from largest to smallest. So, from largest to smallest, from left to right, So, in this case, this is similar to a small scanner that you can use to scan in your photos or whatever. Well, this company has done an analysis and found that people are returning the scanner because of some problems. Well, the number one problem is that our customers don’t know how to use them. They don’t understand our software interface or how to use the device. The scanner. The second is the tractor, the mechanism that moves the light back and forth inside the scanner. And then the light itself is either burning out, defective, or not working properly.
Then it’s the USB connection. People are having some problems with that. Or when they return their product, it could be the interface. They don’t understand our buttons to press on the scanner. And then you’ve got just some miscellaneous stuff. So the idea of the predo chart is that we’re going to take 80% of our effort and work on improving our biggest problem here, which is skills. And we believe that if we solve our skill problem, the other problems will go away as well. If not, or even when we do, when the skills decrease, that becomes a problem because people don’t understand our software. To use our scanner, we’ll reorder our predochart, and then we’ll attack the next largest reason for the total number of failures. And so it’s rounds and rounds of attacking these problems, and we reorder them each time that we do an analysis. The little bar that you see, the little curve with those dots going across the top, what that’s showing us is the total number of failures.
So we take the skills plus the tractor, and that equals about 300 of our 500 failures. And then the skills, the tractor plus the light, are about 380, and so on, all the way up to 100%. So it’s just showing the curve from each of our failures to a total of 500 failures. And 100% of the failures are accounted for. And that’s a predator chart. A histogram. A histogram is a vertical bar chart that shows frequency. It’s all a histogram, is it not? It’s just a bar chart. So you have some different values that are being measured here. And you can compare the different teams, management, or vendors to see how they are performing on cost, schedule, quality, or whatever the case may be. It’s just a vertical bar chart to show frequency. And that’s the histogram. Now, a control chart. This is one I really want you to pay attention to. And I want you to know for the exam that what you may see in an exam coming up is a chart without any of the terms mapped out here. So you’re going to have to be able to identify these different components. So let’s talk about this. So we have a project where we are setting up a service—a call centre at a help desk.
And our customer says that out of 1000 phone calls, you have to answer 950 phone calls, correct? That’s your minimum. That’s the worst you can do. As a result, we use that information. We now know what our requirements are—the top and bottom requirements. So those thick, solid lines that we see here in our control chart, the best we can do is 1000 out of 1000, right? And the best we can do is 950. We’re below 950; we’re in trouble. So that’s our requirement in that window, between 951 and 1000. And you could apply this to manufacturing or any type of repetitive activity. You could even do it in your project, where you measure in each phase how many defects there are, and so on.
But we’re going to use a call center. Well, we don’t want to flirt with 940. We don’t want to dip down there. And we understand that hitting 1,000 out of 1,000 is probably unrealistic when calls come in. So we’re going to set some control limits, and our goal is to stay within these control limits. Now, the bottom control limit and the top controllimit, we could do plus or minus three sigma. So we could do some normal distribution there. You won’t have to do that on your exam. and I’m not going to do it here. I’m just going to say that if our bottom is 950 and our top is 1000 for our requirements, I’m going to make those more narrow. So I’m going to say that the bottom-control limit will be, instead of 959, 70. And instead of 1000, the top control limit will be 980.
So I just said to tighten it up, 980 to 970. So I’ve said we’ve made it tighter as our goal is to be between 980 and 970 out of 1000 phone calls. We don’t want to hit above 980 because of the time involved, and we don’t want to hit below 970. So that’s our window where we expect, out of 1000 calls, everything to be plotted out; our mean is right in the middle. So it’s 975. So we expect that out of 1000 phone calls, we will consistently answer 975 questions. And that’s our goal. It’s well within our requirements, and it’s also within our control limits. So, in this chart, each point at that small mountain range represents 1000 phone calls. So the very first one, we came in at about 973.
And then the next set of 1000 came in at about 978, and so on. Now you can see we’ve got a couple of peaks there. What we did well was that we went above our goal of 980, which we said we didn’t want to be above because sometimes you would have to be on the phone for days to figure out a problem. So we don’t want to be above 980, and we certainly don’t want to be below 970. Well, when an item’s result of 1000 measurements is above or below our control limit, that’s called “out of control” because it’s above or below. We expect it to be in this window because it is out of control. So you can see at the bottom, we have a really big dip. We’ve got two instances that are out of control. So it really fell off the chart here.
So it’s been out of control two times. So that’s an assignable cause. There’s some reason why we had the experience of a thousand phone calls. Really? 2000 phone calls, 1000 in a row, were way below our requirements. They were out of control. That’s an assignable cause. An assignable cause means there’s some reason why you went out of control.
So it could be that maybe there was a new driver that came out, or Windows did an update, or there was a virus that got loose on the network—who knows? But there is one thing we must figure out: why did we have this out-of-control experience with 2000 phone calls, 1000 in a row? The next thing we need to look at is an assignable cause. That’s called the Rule of Seven. Whenever you have the results of seven consecutive measurements on one side of the mean, that is not random. There’s a pattern or a trend here. And so that’s called an assignable cause. In this example, we have the results of seven all on one side of the mean. As a result, it is below our average. This could be because our goal is too high and it’s not realistic for us to hit 975 consistently.
Something is most likely happening because we’ve done it before. Maybe we have new employees, there’s new software we’re supporting, or calls are coming in much more frequently now. Who knows? But something’s happening there. There’s a trend. So that’s an assignable cause, and that’s called the Rule of Seven. No. The rule of seven All right, so that’s a control chart. Next up is a scatter diagram, our last of our seven quality tools. a scatter diagram. A scatter diagram shows the relationship between two events, and you’re looking for how closely they trend together. So does quality improve whenever we do maintenance? So if that were the case here, you could see early on that, yes, quality does improve, but the farther away we get from maintenance, the more defects we have. The more that these trends coincide, the more likely they are related. That’s a scatter diagram. It shows two variables. The closer they trend together, the more likely they are related. All right, good job. That concludes our discussion of these tried-and-true quality tools. I’ll see you in the next chapter.
SY0-501 Section 1.1- Implement security configuration parameters on network devices and other technologies.