- Welcome to module eight part one where we start talking about quality. And in the quality theme, for foundation we need to talk about how we manage quality, we'll introduce some language, so we're talking about the difference between customer expectations and acceptance criteria. We'll also take a look at a number of management products. We also need to clarify the language regarding quality planning, quality assurance, and quality control. The purpose of the quality theme, which you'll find in the book, is to define and implement the means by which the project will verify that products are fit for purpose. So we've got to create a strategy or an approach to ensure that we make products that are fit for purpose. So fit for purpose is really the phrase we use when we're thinking about quality. So it's a very paired down definition of quality for us. We don't want to, sometimes you hear people talk about customer service, meet and exceed customer expectations. We want to meet customer expectations with what they tell us is fit for purpose. So have a think about that language and whenever you see the words "fit for purpose" think quality. When we are defining quality it's useful to understand these phrases here, this language. First up we have customer's quality expectations, and we need to go to the customer and ask them what would be fit for purpose. What are their quality expectations? And if we look at the Prince2 definition for this, they say it's a statement about the quality expected from the project products. Now -- bolded those words there because that is the thing. The project product is the final product. So if we're building a car it's the completed car. And we will need to go to the customer and say, "Well, what do you want in your car? "What kind of car do you want?" And they might not always know exactly what they want. So they want to say "Well, it's a big car, it's a fast car." Well, you say "Well, how big, how fast?" So customer quality expectations are often expressed in broad terms. It can be quite vague on occasion. Sometimes you'll find a customer who knows exactly what they want. Great, fantastic, we love it. But a lot of the time we find ourselves in meeting, speaking to a customer or user, asking them what they want and they're not really quite sure. They want all the whistles and bells. They want the sun and the moon and the stars on a stick yesterday. They'll use quite vague terms to express what they want. We can't deliver those vague terms. We need to be a lot more specific about what we're going to do. So we need to speak with the customer, with the user and say "Well, okay, so you want it to big or you want to be fast. "How big, how fast exactly "and what do you mean by those words?" So we need acceptance criteria. And acceptance criteria are a prioritised list of measurable criteria that the project product must meet before the customer will accept it. So some key words there that I've put in bold. The acceptance criteria must be measurable. So they want it to be big. Well, how big? We need it to be, we'll need to have a target of how big it should be and it should be a measurable target. So they say "We want it to be X number of metres long "or X centimetres high or millimetres probably." And then at the end of the project we will have shown the measuring tape against the car and we'll say "Right, okay, we did deliver it to the right size." And then there's no reason for the customer not to accept it. If we have delivered all of the acceptance criteria then the customer cannot at the end of the project when we close say "Well, no, that's not what I meant. "I wanted it fast and you haven't done it "as fast as I wanted it." We need to go through this process. It's not always an easy process. We ask the customer what they want and they will say "Well, we want it big and we want it fast." and then we have to go through the next step to say "What exactly do you mean by that," and put it in the form that we can deliver by project closure. So the key word for here for acceptance criteria is it's got to be acceptable. So we've got to put it in terms that we can definitely prove at project closure. Quality criteria is another phrase you might come across and quality criteria is no longer talking about the final products of our car for example. We're talking about quality criteria of some of the component parts of that car. So quality criteria is, as they put it here, a description of the quality specification that an individual product, an individual product must meet before it can be approved. So for the other two customer quality expectations it is about what the final product must deliver to be acceptable at project closure. For quality criteria it's what an individual product must deliver before it can be approved. So the project product has acceptance criteria and customer quality expectations that help us get us to the acceptance criteria and the products have quality criteria for what we should deliver before they can be approved. So we will record this information in two different places. So you can see in the acceptance criteria there and in customer's quality expectations these are captured in the project product descriptions. We have one document, the project product description, what will contain what the customer wants, our customer quality expectations, and what exactly the product has to deliver in order for this project product to be acceptable, those two things in the project product description. And we will have just one project product description but the customer's quality expectations and acceptance criteria for the whole project. And that last one, quality criteria for individual products, that's captured in product descriptions. So we will need a product description to describe the quality required in the wheels or the head lamps or nice cushioned seats. Even every switch and LED light fitting probably what may need and certainly in the manufacturing industry it certainly would have a separate product description. So it's really up to the project manager and the board to work out in sales about what exactly needs a product description. In some projects you would only have the major products being given a product description. But certainly for all our major products we will need to decide that the quality criteria will be. Let's have a look at the management products then, and I mentioned these in the previous slide but let's look at them more carefully and just separately. We have the project product description, that's A.21, so find that in appendix A, that's the 21st entry there in appendix A. And according to the Prince2 manual, this is a special kind of product description that defines what the project must deliver in order to gain acceptance. So notice those words that I've bolded up there, is what the project must in order to be considered acceptable to the customer. So we're gonna look at those acceptance criteria and write them in here and make sure we've met those acceptance criteria by the time we've closed. Then we have our product descriptions. These are used to understand a product and then maybe many of those. We need to know the level of quality required in each of those products. So we're going to make some wheels. How many? So the requires we need four. How are we going to make it, so what skills and activities are required. How are we going to test it and who is going to approve it? So each product description will take one part of the final product, which is described in our project product description, and look at how it's going to be produced, reviewed, and approved. So there will be only one project product description or PPD as it's written there, but there will be many product descriptions or PDs as it's written there. So got it? One project product description for the final project product and potentially thousands of products descriptions that we need to write for the individual products that will make up that final product. So those are the management products for the quality theme and that's the end of part one.