PMI PMP Project Management Professional – Project Quality Management

1. Section Overview: Project Quality Management

Welcome to section 14 on Project Quality Management in the Pinback Guide. This is chapter eight on Project Quality management. So we’re going to discuss here what is quality, what does it mean to manage a project and have quality in that project project, we’ll look at considerations for adaptive environments, some key concepts you need to know for quality. We’re going to look at the cost of quality or the cost of poor quality. So some differences there and characteristics there you need to recognize. We’ll talk about creating the quality management plan, how you adhere to quality. And then tied to that, we have an opportunity to improve processes.

So we’ll see in the quality management plan some things we want to pay attention to, to improve the process, not just inspect the results. A little hint of what’s coming up. We’ll talk about managing quality, the results of managing quality, controlling quality, where you have the most influence as the project manager, and then creating some different charts you need to know, like an Ishikawa or a control chart or a predo chart. So some things we’re going to look at in this section. And then we have an assignment, a quality case study. So I know you’re excited about that. And then I want to talk to you about meeting your quality goals. So a lot of information to COVID here in this section on project quality management.

2. Looking at the Big Quality Picture.

You know how important it is to obtain quality in a project. But what exactly is quality? One of my favorite definitions of quality is that quality is the totality of an entity that bears on its ability to satisfy stated or implied needs. So if we break that down, quality is the totality of an entity. It’s everything about a product, a service, a condition or result.

So it’s the totality of an entity that bears on its ability, that affects its ability to deliver stated and implied needs. It’s the implied needs that often trips people implied needs. We’re talking about some of those non functional requirements. So this just shows us how important it is in scope management to have a clear definition of what constitutes quality. We want to stay away from those subjective terms like good, fast, reliable. What does it mean to be good? What does it mean to be reliable? What is fast? So we want to nail that down so we have metrics to aim for in our project. The big quality picture is where we’re looking at the whole picture of quality. That it’s the totality of what we’re creating, that it’s the needed abilities to reach those goals.

The goals being business value and stated and implied needs. Some terminology you need to know for your exam about quality. We need measurable terms. So those subjective terms, we get away from those. Our goal is to really understand the requirements and to have clear requirements, and that helps us deliver requirements. If we know exactly what we have to deliver, then we can achieve quality by delivering exactly those things. Of course, we want to beware of gold plating. Sometimes there’s a mindset that I’m going to go above and beyond what was requested. That is not quality. Quality is meeting exactly what was required of me. So even if I have time and money to create additional things that’s gold plating, I give the customer exactly what was requested.

So for your exam, think very clearly about quality and requirements are linked. In order to achieve quality, we deliver the requirements. No gold plating. Now, I know out in the real world you might go to that stakeholder and say, we have time and money and I understand what you want and we can do X-Y-Z. Nothing wrong with that at all. But for your exam, you might be painted into some corners where you have to choose, do I go ahead and do something and spend the money? Or do I deliver exactly what was requested? You want to deliver exactly what was requested. Our goal in quality is to have customer satisfaction by delivering the exact requirements. Our requirements need to have a conformance to requirements.

Our quality conforms to requirements. We need to have a fitness for use, that it’s usable, that it’s fit, that we can walk away from that project knowing we gave the customer a good product, a quality project, that we delivered exactly what they asked for. Prevention is also part of quality. We want to do the work correctly the first time. So quality is planned into a project. It’s not inspected into a project. We have a management responsibility. Now, management responsibility means that above the project are managers. Those functional managers.

That middle management. If they say zero defects, that’s fine. We can have zero defects, but we have to have the tools and the time and the money to achieve zero defects. So there’s still a management responsibility. There’s a theme you should be familiar with when it comes to quality, and it’s based on w. Edwards dimming’s plan, do, check act, or sometimes called the dimming cycle. So we plan, we do, we check, and we act upon those results, and it’s iterations. So PDCA plan, do, check, act. In this section, we’re going to talk about three quality management processes. So we have quality management planning, we have managed quality, and we have control quality. All right, let’s hop in now and look at these three processes.

3. Key Concepts for Project Quality Management

So far we’ve been talking about quality in regards to the product, the service, or the result that we create. We also need to have quality in our approach and how we create that product or the end result of our project. So the quality management approach is this mindset of taking a top down approach to quality, that we don’t just do the right work, we do the work correctly, we do the work rightly. All right. So we’re doing things properly and with precision and with accuracy. A couple of terms we’re going to look at in a moment. We want to beware of overworking the project team. If you overwork the project team, if you’re forcing lots of overtime or you’re forcing a lot of weekends, that’s overworking the team. And the team is going to get worn down.

They’re going to get well unhappy about all that overtime or extra hours, and they might rush through the work, or they might have poor performance. And so that can cause quality to suffer. That’s a key fact you should know for your exam. We also want to be aware of speeding through inspections. If we have quality control inspections scheduled, like at the end of a phase, we shouldn’t rush through those just to stay on schedule. We need to make certain that what we’ve created is of quality and then act accordingly. If you rush through those inspections, you might have some poor quality, some escaped defects that the customer sees, which we don’t want. There are three terms when it comes to quality management that you should be familiar with.

We have prevention, inspection, and attribute sampling. Prevention is this idea of quality control, that we keep mistakes out of the customer’s hands, that we want to ensure that the work that we do is done properly, and then we inspect it. And if there’s a mistake, we do corrective action. We might have to do defect repair. Inspection is how we do quality control, that we inspect the work and we keep mistakes out of the customer’s hands. Let me back up to Prevention for a moment. I kind of misspoke there. I want to be very clear. Prevention is keeping errors out of the process, and I said out of the customer’s hands. Prevention is keeping errors out of the process, that we want to do the work correctly. We don’t want to allow mistakes into the project at all.

So this is the idea that quality is planned in. Your organization might have some six Sigma or some other quality assurance program. You don’t need to know about six sigma for your exam, but it’s a QA program. The goal is to do the work properly, to reduce defects by doing the work correctly. So Prevention, we don’t want errors to come into the process. Inspection is quality control that we go out and inspect the work and we prove that it’s of quality. And if we find a mistake, we fix it before the customer sees it. Attribute sampling is where we look at the attributes of what we’re creating. At each attribute of what we’re creating.

We can look at it and test it, and we can say that the results either conforms to requirements or it does not conform. It’s binary, it’s good, and it can go on or it’s bad, and we need to fix the problem. So attribute sampling is where we go out and we look at the attributes of what we’ve created. Some other quality management terms here. Variable sampling. Variable sampling is where the results of what we inspect are rated on a continuous scale that will see the measure of conformity. So how close are we to perfect? And there might be a window there that it’s acceptable or outside of that window that it’s rejected, and you have to do the work over.

And that’s called a tolerance as that window. That what’s acceptable versus what requires rework. And then control limits. These are the boundaries of the common variation. So we’re looking for a stable process in order to have control limits. And with control limits, as we’ll see coming up later in this section, we can create control charts. So control limits, we set a specification for what’s the max or the lowest that we could have in our tolerance, in our errors and defects. So we’ll look at that coming up in a little bit more detail. Let’s talk about accuracy and precision and how it relates to quality. Precision is a measure of exactness.

Accuracy is an assessment of correctness. Precise measurements aren’t necessarily accurate measurements, and accurate measurements aren’t necessarily precise measurements. So let’s put this into a way we can all relate. Let’s say that you and I and my brother Sam, we’re going to go out and shoot this bow and arrow, which looks very complicated, but we’re going to go out and shoot this bow and arrow. And you go first, and you shoot five arrows. And all of yours hit in that yellow area right by the bullseye, all clustered up together and right where you want them to go in the bullseye. Then I go, and mine all cluster up, but they’re in the upper right hand corner in that black area on the bullseye.

So not where we want to go. They’re kind of drifting up into the right. And then my brother Sam, poor guy, he takes it. He’s missing the target. He’s all over the target, not very good at all. So how does that relate to accuracy and precision? Well, precision is a measure of exactness. It describes the clustering. So mine were precise. They were all clustered together. They were very precise, but they weren’t for what we were aiming for. Yours were accurate right where you wanted them to go in that yellow area in the bullseye. And yours were precise. The precision was where you wanted them to go. So they were bunched up together and they were on target.

Now, my brother Sam, his were not precise. They were all over the place, and they weren’t really accurate because he didn’t hit the bullseye. So precision and accuracy are linked, but just because you’re precise doesn’t mean that you are accurate. So we need to make a distinguish there between what’s precise and what’s accurate. Our goal is to be both. We want precise and we want accuracy. We want to be accurate in quality project management. There’s a concept called Kaizen Technologies. And I love Kaizen. Kaizen Technologies tells us that with small, continuous improvements, we can make big changes over time. When I was training to run a marathon, I know, can you believe it? I did Kaizen Technologies that I could barely run a block, let alone 26. 2 miles. So I started out, I would jog to a mailbox, and then I would walk to the next mailbox and then run to the next mailbox and then walk again. And then a week would go by, and then I would run for two mailboxes and then walk for a mailbox and then three and so on.

So over time, I did a little bit and a little bit and a little bit, and it was easier to accept that concept of running a mile or 10 miles or 26. 2 miles. So kaizen are these small improvements? The idea is that it’s easier for an organization to take on small improvements, small changes in processes, than to have big, sweeping changes all at once. Just like if you said, Go run a marathon, there’s no way I would have been able to do that. It would have been beyond my imagination. But by doing these small steps, I was able to chip away at it and eventually got to the point that I could run a marathon. We won’t talk about how fast or slow I was. Marginal analysis is where we do a study on what would it take to improve this product or service, and then how will those cost allow us to sell more? How will it have a return on investment? So can we improve upon this clicker and make it more efficient, make it better for the user? But what would it cost to make it better?

It’s just something the user even wants a better clicker. All right, so how much would it cost, and would this allow us to sell more, or would it reduce the cost of manufacturing this? So, marginal analysis is the study of, can we spend a little bit more? But what’s the ROI? And then part of marginal analysis as well is what would it cost just to create one more unit? Sometimes you get that at Christmas time or at different times in the year when you want to order a big batch of your cards to send out to friends and family, like you move or a holiday or what have you. So they say, all right, if you print ten cards, it’s going to cost you $12. If you print 20 cards, though, it will be $15. So the marginal analysis is, well, can I print a few more? And now I have double the amount of cards, or nearly double the amount of cards for just a few dollars more.

But do you really need those extra cards? So marginal analysis is also the study of that concept of what would it cost to create one more unit in your organization. As I mentioned, you might have a quality policy, like a quality assurance program. So you might know these by different names. Like I mentioned, Six Sigma, but also total quality management. Usually have that in manufacturing and then ISO programs. ISO is Greek for unit form, and it means that we do the same process every time to get the exact same result. If a quality policy doesn’t exist, it’s up to the project manager to create one. So how will you achieve quality in your project? So remember, we want quality planned in. We want to do the work correctly the first time. It’s always more cost effective to do the work correct the first time than to have to fix the problem later. Standards in regulations, we’ve seen this a couple of times already. Standards are optional. Regulations are not.

Regulations are requirements. So you have to adhere to regulations even if it takes longer, or it means you have to spend more money. Regulations are requirements. All right, great job. Keep moving forward.

4. Considerations for Adaptive Environments

Quality is important in all projects whether you’re predictive or adaptive. We need to know some nuances though that happen when it comes to adaptive environments. In adaptive environments remember that the requirements are based on this product backlog that can be prioritized before we go into each, each iteration. So our goal is to meet the project requirements but it’s the requirements for our current iteration. So we have a product backlog and then we have what we called an iteration backlog or a sprint backlog.

That are the things we are to create during the current work period during the current iteration or sprint. Project requirements are defined in each iteration planning session. So what’s going to go into this next iteration? That’s the grooming of the product backlog. We do this directly before the team starts the work of the current iteration. Once we’re in motion, once the team goes into that iteration there are no changes for that iteration that are allowed, no changes to requirements that are allowed at that time.

Some other considerations for adaptive environments the product owner and the development team really work together and they look at the product backlog and they gauge how much labor it will take to create a given chunk of those requirements in the current iteration. So we have user stories and one approach is to use what’s called user points or story points so that the stories have x amount of points and we can only do x amount of points in this iteration. So it’s a way to size the number of requirements that we can take on. So we don’t want to over promise and then under deliver. We want to give exactly what we can create in the current iteration.

The team, the product owner and the project manager, they all work together because they want to know exactly what these user stories, what exactly I’m to create. So that helps gauge how much work can be done in the current iteration. Now quality reviews are built into the agile process or the adaptive process. So quality is part of the process and at the end of each iteration there’s a meeting called a retrospective. The retrospective is we’re looking back on the last iteration and we’re doing this with the project team and the project manager.

So we’re saying what did work or what didn’t work and how can we improve upon that? So it helps the team and the manager make any adjustments to processes so in future iterations we have a better opportunity of being successful. It also helps with the improvement to the execution of the work. Like okay, we took on too much, we were too aggressive in the amount of user stories that we could do in one iteration. So in the next iteration let’s be a little bit more conservative, a little bit more realistic. All right, so those are all some facts that you need to know when it comes to adaptive environments and quality.

5. Quality and Grade

Let’s talk about quality and grade. There is a real difference between quality and grade, and sometimes it’s easy to get these mixed up. Quality is all about fulfilling requirements. So we’re talking about meeting the project scope, creating the product scope exactly as it was required. Requested. We have implied needs there. Low quality is always a problem when it comes to our project. Now, grade is a category or a ranking of products, of materials, of processes or services. So we have a ranking like first class versus coach, like plywood versus oak. So it’s a ranking. They’re both wood, but they have different technical specifications about how we’re going to use that thing and its characteristics. That’s a grade. Low grade may be needed.

Maybe you need plywood because it’s a short term, temporary solution. Low grade isn’t necessarily a problem. Low quality is always a problem. So on your exam, when you’re talking about different types of material and how one is preferred over the other, but you can’t afford it. Well, if you’re talking about a ranking of materials, we’re talking about grade. If we’re talking about a specific type of material that’s required, we have to have that type of material in order to meet requirements. So we’re talking about quality, about having the the correct material, the correct tools and equipment and resources. That’s all tied to quality. But the ranking of that stuff is tied to grade. So quality and grade go together, but there is a difference.

6. Planning for Quality

We need to plan for quality. Our first process of the three is to plan quality management. To plan quality management means we’ll create a quality management plan like our other knowledge areas. This is a subsidiary plan that’s part of the overall project management plan. And it defines defines how will we do the other processes in this knowledge area. So basically it defines how will we manage quality and how will we control quality. Let’s take a look at plan quality management. So it defines the quality policy for the project, defines our QA requirements and defines quality control or control quality. What are those activities like? The quality planning process is an Iterative activity that happens throughout the project. Remember, planning is iterative.

You come back to it whenever it’s needed. There’s a PMI theme you should know for your exam. I plan, I implement, then I measure, I react and I document outcomes. So plan, implement, measure, react and document. If the product, what we create is not acceptable, then the project isn’t done. We have poor quality. We have to make it acceptable. We have to meet requirements in order to be successful. All the way back to chapter four of the Pinbox. When we created our charter, we had success criteria. That’s why we need success criteria. That’s why we need clear requirements. We don’t want buzzy requirements because then we get to the end of the project and the customer inspects it in scope validation and they say well, this isn’t what I wanted and you had a misunderstanding. We have poor quality, we have an issue.

Now we have to resolve. The scope must be met in order to achieve quality, that those two are dependent on each other. So the scope has to be created to achieve quality. And in order to have quality, you have to meet scope, which means I have to have clear requirements. Let’s look at the EDOs for plan quality management. Our inputs, the project charter, the project management plan, the requirements management plan, the stakeholder engagement plan and the scope baseline, several project documents, the assumption, log requirements, documentation requirements, traceability matrix, the risk register and the stakeholder register.

And of course we have EEF and OPA. Lots of tools and techniques here for planning quality, expert judgment, benchmarking, data analysis and data analysis. We have cost benefits analysis and the cost of quality. A couple of new terms here, decision making there’s that multi criteria decision analysis, data representation, flowcharts logical data model, a matrix diagram, mind mapping and then we will plan out our testing and inspection. And of course we have meetings, the outputs of planning quality. We get the quality management plan. That’s the big output here. But we also have quality metrics. You might have updates to the project management plan, specifically the risk management plan and the scope baseline.

Our project documents updates, the lessons learned register, the RTM, the risk register and the stakeholder register, that those are all outputs of plan quality. We really need to think about the five key inputs for planning quality. Very important. First off, the project charter. The charter, remember, gives us the high level project description. It also tells us how do you know if this project is successful? So what are the measurable outcomes to determine success? The project management plan is needed because it has that integration management. That what I do in quality affects the rest of my project. So you think about the requirements management plan and the risk management plan, the stakeholder management plan and the scope baseline.

Let’s talk about the risk management plan for a second. This is chapter eleven in the Pinbach guide. The risk management plan is needed because what risk may have a negative effect on quality. So what risk threaten the ability to hit those success criterias? And if we have a risk happens that will threaten our quality, then we have to plan accordingly. So we haven’t really talked about risk yet. It’s coming up in a few sections, but it’s important with quality planning. The project documents for planning, the assumption log. Remember, it’s really assumptions and constraints. So assumptions, if they prove to be not true or they prove to be false, that can affect quality.

The requirements documentation, of course, because that’s what we’re trying to meet in order to have quality. We have our RTM because remember, it traces the requirement through all of our phases. The risk register tied to the risk management plan and then the stakeholder register because we want that collaborative relationship with our stakeholders. And then we have enterprise environmental factors and OPA. I know I kind of breeze over those sometimes, but it’s important to acknowledge these, especially for quality, because we’re talking about regulations, rules, standards. What about the geographic makeup of the project, where resources are, where the project work is taking place that can affect quality?

The organizational structure, marketplace conditions? What about the working conditions? You’re out in the field or in a dangerous environment that can affect quality. And there could be some cultural perceptions that affect quality. With OPA we’re talking about templates, check sheets. So I have tactivity to install thousand fixtures. I have a check sheet to do it correctly every time. And historical information, if I’ve done this type of work before, can I take that work and adapt it to the current project so historical information can be used for planning quality? All right, great job. You’re making great progress. Keep moving forward. I have confidence you can do this.

7. Applying Benchmarking Practices

We’ve seen benchmarking several times. As a tool and technique, benchmarking is an opportunity to compare one thing to a similar thing. So I could compare SQL and Oracle. I could compare a senior engineer to a junior engineer. I can compare different materials and how they may work best in our project. When it comes to quality, though, it’s all about measuring one item against the other. And how does that most accurately and precisely deliver quality? So what’s the best choice for our project? We can also do measurements against other projects.

So we have a similar project and how is it performing? We should be able to perform as well in this current project. Benchmarking the goal is to evaluate the differences between projects. In chapter seven in the Pinbach, we talked about earned value management. So I could take two projects in two different disciplines, healthcare and It, or manufacturing, or even all three of them, and I could benchmark those based on earned value management. I could see what’s the CPI for each one, what’s the cost variance for each one, and I would have an idea of which one’s performing best. This helps me take corrective actions for my current project.

So I can benchmark before and after we make an adjustment. I can create some false goals though, when I benchmark, and also create some internal competition. So inside the company, if we’re comparing projects, then we have to be very accurate in our reporting. Because if Bob over there is telling us that his project is at zero point 99 CPI and we’re at zero point 95, but in reality he’s at zero 91, then our project looks like it’s not performing as well as Bob. So let’s emulate Bob’s project when really Bob’s project is not doing so hot. So truth in reporting is mandatory when we’re benchmarking two different projects. Benchmarking just to be clear, I’m comparing two different systems. I’m comparing technologies, materials, or projects. You can also use benchmarking to test the materials for what material is best suited for your project. All right, that’s benchmarking.

8. Design of Experiments

Sometimes in quality, especially quality planning, we don’t know what the best outcome would be from a decision until we make the decision. So design of experiments is a way to test variables to find the most appropriate outcome for our project. So I love to give this little scenario here we have these three different postcards, and the postcards are an invitation to come visit Florida. I live down in Florida, so I want you to come visit Florida.

And so these postcards are a marketing campaign, and we’re going to mail out a million postcards. But those are our three choices. So rather than just picking one and dropping a million postcards in the mail, what we’ll do first is we’ll mail out 100,000 of each one of those. So A, B, and C will do 100,000 each of the 1 million addresses we have.

Whichever one of those campaigns gets the best results, we get the best response from that will be the postcard that will mail out the remaining 700,000. So the best results win. You might do this if you’re painting. You ever painted your house and you put up three or four swatches of paint and just kind of live with it for a day or two or a week or two, and you just want to kind of get the feel and see how the sun sits it. And what does it look like when the fresh paint begins to fade a little bit?

So that’s design of experiments. It’s a way of comparing results to determine what decision you’ll make for the remainder of the population, the remainder of the activity, whether it’s painting the whole house that color, or mailing out these postcards. Okay, that’s design of experiments.

9. Trend Analysis

Welcome back. Let’s talk about trend analysis. A trend is where you begin to notice a pattern, and that pattern can predict future results. Trend analysis can be dangerous, though, because not always will past performance indicate future performance. A great example of this, if you’ve ever gone to a casino and looked at the roulette table and they have a little sign there of hot numbers.

So all the numbers that have been hitting and then people will say, oh, well, 17 is hitting a lot. I’m going to bet on 17, and then it doesn’t hit anymore. Just because it happened in the past doesn’t mean it will happen in the future. However, if 17 is consistently time after time after time coming up, or three out of five times or four out of five times, then that might be a trend. Maybe that wheel is slightly off kilter, causing the ball to find that side of the numbers. Who knows? But my point being, past performance does not always predict future performance. To apply trend analysis, we’re talking about technical performance. How many errors have you experienced up to this point? And do you notice a trend?

Is it always with the same type of deliverable or the same type of activities? How many additional errors are you experiencing since those last errors were addressed? So was there a before and after? And so if so, did the errors go down or up or remain the same? So that activity you did, that corrective and preventive actions you may have taken, did they affect the outcome of these new errors you’ve deducted or that you’ve analyzed?

So, trend analysis, some ways to do trend analysis cost and schedule is one of the big things we’ll do with trend analysis. So how many activities were completed incorrectly in this time period? What about the delivery time? How long did it take for delivery, deliverables or for a vendor? And where there are cost variances? And are we beginning to creep off of our cost baseline? And so we’re consistently trending away as far as cumulative costs for errors. Those are the types of trends that we can do pretty accurately in project management. All right, so that’s trend analysis with quality control.

10. Tailoring the Quality Management Processes

We can tailor the quality management processes. So based on the project priority, based on the rules in your organization, you can tailor quality, you can tailor quality planning, managing quality and controlling quality. But first we have to think about what existing quality policies do I have to adjust, adhere to? I can’t tailor my way around those quality policies. Those are part of enterprise environmental factors. So I have to do those policies, I have to adhere to them. Part of OPA and to some extent EEF, you may have some quality tools and techniques and existing templates that you have to use. And so those are things that I can’t tailor out of the project.

What we’re talking about with tailoring is to what depth do I need quality planning? To what depth will we do managing quality process, to what depth will we do quality control or controlling quality, as it’s called in the Pimba? Some things to consider here. What about standards and regulatory compliance? Can I tailor those standards? Yes. Usually regulatory? No, you have to adhere to regulations. Regulations are requirements. So what quality standards exist in your discipline, in your application area that you’re allowed to tailor, that would help your project run more smoothly? And then are there any specific regulations, laws or legal requirements in your discipline that you must adhere to? There’s no shortcut around those, that regulations are requirements.

You can’t tailor those. Continuous improvement, though, is how will quality be managed? So all the processes, the 49 processes, how will quality be managed and can you execute those processes? Can you do those processes with quality, and can you tailor those processes at all? Is it managed at the organizational level, so like a PMO?

Or can each project tailor your processes? So you have to know the rules when it comes to how quality is managed or expected to be managed in your organization. Stakeholder engagement is also important when it comes to quality. If we think about the big picture here, the stakeholders, the customer of the project, they’re the most important person in the project. The stakeholders set the requirements. So the requirements are for the stakeholders, for the deliverable.

So we want a quality product to meet requirements to satisfy stakeholders. When we talk about quality, we’re talking about conforming to requirements. And requirements came from our stakeholders. So we want this collaborative environment with our stakeholders and also with our suppliers. So collaboration is really important, and that fits into tailoring to what depth will you do stakeholder engagement? We’ll see stakeholder engagement in much more detail in Chapter 13 of the Pin box with stakeholder management. All right, good job. Keep moving forward.